About Me

My photo
I am a kind of person who is looking forward to build a progressive career in a challenging environment and to present myself with best of my innovative ideas and technical skills. I have completed B.Tech in COMPUTER SCIENCE & ENGINEERING with “Honours” from College Of Engineering Roorkee (COER), Roorkee, affiliated to Uttar Pradesh Technical University,Lucknow. M.Tech from UTU, Dehradun. Ph.D pursuing from AMITY UNIVERSITY, NOIDA. My research areas are Data Mining and Data Analytics. Software Engineering, Artificial Intelligence.

Thursday, September 17, 2009

What hackers don't want you to know ?

Improving Security: What hackers don't want you
to know
May 2007
Executive summary – Hacker techniques continue to evolve. Are the "good
guys" keeping up? Many myths and misconceptions pervade the IT industry
and create vulnerabilities in critical infrastructures. And there are new issues
around Bluetooth hacking, Web 2.0 vulnerabilities, weaknesses in biometric
technology and radio-frequency identification (RFID) exposures.
Understanding the risks and taking a few simple steps can help you avoid
getting hacked, even as the IT environment becomes more complex.
In this Executive Technology Report, Peter Andrews interviews Jeff Crume,
who works as IBM executive IT security architect in Raleigh, NC. He is
primarily involved with supporting the Tivoli security software. He is the author
of “Inside Internet Security: What Hackers Don't Want You to Know.”
Peter Andrews: I know that your interests in security extend to the activities of
hackers. Could you say a bit about what you have been doing to understand and
counter them?
Jeff Crume: My "day job" deals with trying to help customers build architectures that
are secure, which involves mostly identity and access management technologies.
My "hobby" is keeping up with the latest hacking trends because: 1) it's interesting to
me and 2) it helps me do better in my day job by being more aware of what I'm up
against.
Peter Andrews: Tell me about some to the misconceptions people have about
hacking.
Jeff Crume: There are many. So many that I wrote a book about them called Inside
Internet Security: What Hackers Don't Want You to Know. In the book, each chapter
is basically dedicated to a myth or misconception that seems to pervade the
industry. It's easier for the "bad guys" to do their job if the "good guys" keep
believing stuff that isn't true.
One common myth is that all the "bad guys" are "out there" – meaning they are on
the other side of the firewall and, if we can just do a good enough job of keeping
them out, that we will be safe. The truth is that a significant number of attacks are
inside jobs – either by current or former employees who have either misused the
privileges they have been given or whose access rights have not been removed in a
timely fashion.
ibm.com/bcs
Executive technology report
1
Maybe one of the biggest myths is that an operational computing system can be
made invulnerable to attack. The truth is that any system can be broken into if an
attacker is sufficiently motivated and given enough time. Our job then is not to have
perfect security with no risks (because that can't happen), but rather to have
adequate security for the task at hand and take prudent risks that we can tolerate.
All the time I see architectures that fail to provide means for protecting sensitive
resources once an attacker penetrates the outer defenses. It means that if the
hacker can get past the front door (metaphorically speaking), then there is little left to
keep him from stealing the keys to the kingdom – and if that hacker happens to be
an employee, then getting past the front door is trivial.
Peter Andrews: Could you tell me about the consequences of such a security
breakdown?
Jeff Crume: Since I'm on the presales architecture side, I usually am spared the
task of seeing the "train wreck" after it happens. However, all you have to do to get a
taste is to follow the trade press and see how every week break-ins are being
reported where the identities of tens of thousands of customers have been
compromised. Most of these happen as a result of stolen laptops, but a significant
number are the result of break-ins at a computing level.
Peter Andrews: How do you possibly restore order after this has happened?
Jeff Crume: Since my work focuses on prevention rather than remediation, I'm
probably not the best person to say. But I do know that there are a growing number
of regulations that specify, to some extent, what actions an organization must take.
For instance, the 30-some-odd, state-by-state disclosure laws require that the
organization notify all its employees/members/customers whose data might have
been compromised.
The best way to prevent this in the first place is to ensure that you have adequate
access controls in place, a good system for granting and removing privilege levels
(provisioning/deprovisioning), good encryption of sensitive data and a means for
monitoring it all so that you know when a breach has occurred.
Peter Andrews: Are the people you work with highly motivated to get this right? Or
does it seem to some to be too much of a bother?
Jeff Crume: I see both types all the time. The ones who are the most motivated are
the ones who have the threat of regulatory noncompliance hanging over their heads.
The Sarbanes-Oxley Act (U.S. accounting regulations) has done more to provide
this level of motivation than anything because it holds corporate officers personally
responsible for failure to ensure that adequate internal controls are in place. When
your CEO might go to jail, the organization tends to put that at the top of the priority
list.
ibm.com/bcs
Executive technology report
2
Peter Andrews: Any advice on handling those who are less engaged?
Jeff Crume: (The) best thing might be the judicious use of "war stories" – trade
press articles about the consequences that other organizations have faced when
they failed in this area – and there is more than ample supply of such evidence.
Peter Andrews: That brings up the people aspect of security. I know that "social
engineering" is a big problem, as is training. Do you get involved in these aspects?
Jeff Crume: I don't, but I do cover it in the book. It's a huge problem because no
matter how good you lock down the infrastructure, people are almost always the
weakest link and will continue to be so until we develop a firewall for the human
mind – and I'm not holding my breath on that one. :-) Inadequate training is a big
contributor to the problem.
Security departments just end up saying "no" to everything rather than explaining
why. Security awareness training needs to be more than a few posters or slogans. It
needs to involve real education.
The other thing is that technicians need to be more sensitive to the needs of the user
community. It doesn't matter how secure they think they have made a system if they
have made the users’ jobs so untenable that they feel compelled to violate the policy
in order to get their work done.
Single sign-on (SSO) is a great example. Telling users they have to keep up with a
dozen different, hard-to-guess (therefore, hard-to-remember) passwords that must
be changed every 60 days doesn't ensure that security will be better. The only thing
it guarantees is that people will write passwords down – and they will invariably put
these password lists in conspicuous places, thereby making security even worse
than if a looser password policy were to be allowed.
I’m not advocating for “anything goes” when it comes to password selection, but it’s
important not to fall into the trap of a false sense of security that many security
departments end up in. Single sign-on, however, makes life easier for users without
compromising security (if it's done correctly). That means a win-win for everyone.
Peter Andrews: Is there a step by step that allows them to explore their users’
needs and accommodate them? Or some rules of thumb?
Jeff Crume: I think the main things are to make security awareness training an
ongoing activity that is more than just posters and slogans on pens, but involves
some compelling, interesting education on what the risks really are. This CAN be
done in an entertaining way, but rarely is.
The training should focus not only on the "thou shalt nots," but also on the "whys."
You will never be able to come up with enough rules that will handle all situations,
and even if you could, users couldn't possibly be expected to remember them all. So
the focus should be on the underlying principles that make for secure behaviors.
ibm.com/bcs
Executive technology report
3
Peter Andrews: Shifting topics a bit, could you talk about some of the new
technologies, like biometrics, and how they might provide (or not provide) some
answers?
Jeff Crume: Sure. Biometrics can be a blessing or a curse. The problem is that
most people don't really understand them. That's why a big part of my presentation
at the Technical Leadership Exchange is dedicated to trying to dispel some of these
prevailing myths. Biometrics are not necessarily more secure than other means of
authentication. They may be more secure – or they may be less secure – depending
upon how they are implemented. All we know for sure is that they are more
expensive in terms of initial, up-front costs.
Peter Andrews: Any practical hints? Questions to ask?
Jeff Crume: Too many to enumerate here, but one of the things off the top of my
head that is worth considering is what is the organization's tolerance for false
positives (incorrectly identifying someone as you that isn't you) and false negatives
(incorrectly saying you aren't you)?” Unlike passwords, which either match or don't in
a very deterministic way, biometrics are much fuzzier and probabilistic in nature.
You have to decide how much error you can tolerate in either direction, and the
answer will vary from organization to organization and, sometimes, even from
application to application.
Biometrics, when used alone for authentication, are really more of a convenience
factor than a security factor. (You don't forget to bring your thumb with you). If you
really care about security, you will use a biometric as part of a multi-factor
authentication system that also requires that the user present something they know
(e.g. password) and/or have (e.g. smart card) in addition to the thing that they are
(e.g. biometric).
Fraud detection and data mining efforts have similar probabilistic characteristics in
that you are looking for needles in fields of haystacks. Lots of false positives and
false negatives are the result if you get it wrong. And it's really hard to get it right
unless you have a very well-defined behavior you are looking for.
Peter Andrews: The message is "proceed with caution!" eh?
Jeff Crume: Definitely. Don't assume that more technology always equals more
security. Sometimes it does and sometimes it doesn't.
Peter Andrews: Do some of the new technologies, like Web 2.0 applications, put us
at more risk?
Jeff Crume: Definitely. Web 2.0 leverages a lot of client side, mobile code (a.k.a.
active scripting) such as Java, Javascript, AJAX, etc. It's always a risk when users
have code running on their systems that they didn't explicitly ask to have installed
and have no way to verify its veracity.
ibm.com/bcs
Executive technology report
4
It's a myth that just by visiting a web site that you can't get hacked. There are loads
of attacks that rely on browser vulnerabilities (and there are many regardless of the
browser you choose) to break out of the "sandbox" and have free reign on the user's
system with the highest level of privilege.
I'm not saying don't do Web 2.0, but I am saying that you should do it with your eyes
open and know what the risks are and try to mitigate the ones that you can.
Peter Andrews: OK, short of cutting my cables, what can I, as a user, do to
minimize my risks? Do you have a few essential recommendations?
Jeff Crume: There are many. (By the way, I don't recommend cutting the cables,
but it certainly would reduce the risks.)
1. Run a good antivirus scanner and make sure it gets updated with new
signatures every day (if possible).
2. Run a good personal firewall on every workstation, laptop, etc., and be
cautious about which applications you allow to access the Internet. (Don't
just grant permission to every application that asks for it – if you don't think
that application needs to "phone home," then deny it access.)
3. Don't open e-mail attachments unless you know what they are and what they
are going to do. It doesn't matter if it appears to be coming from the person
you trust most in this world because the source address could be spoofed, or
that person's system could have been compromised.
4. Don't run ActiveX/Javascript/Java in your browser by default if you can avoid
it. Firefox, for instance has a plug-in (NoScript) that lets you easily turn
scripting on and off on a site-by-site basis. This way, you can turn it on for
the sites that you trust and leave it off by default for the ones you don't.
5. Always, always, always keep a good back up. There's no such thing as
perfect security, so you need a back up or you're doing a high-wire act
without a net.
6. Secure your home LAN (local area network), especially if it has wireless
capability. Turn on 128-bit encryption and change the default SSID to
something else that a hacker wouldn’t easily guess.
7. Stay current with patches, especially to key components like the operating
system, browsers, e-mail clients, productivity applications like word
processors, etc. This is very, very important and not that hard to do these
days with the automated mechanisms available.
Again, there are many more, but if most folks would do that, it would go a long way.
Peter Andrews: Great suggestions! Looking forward again, what are the emerging
vulnerabilities or hacker strategies?
Jeff Crume: I think biometrics and Web 2.0 are two of the more interesting ones
we've already discussed. Others involve the pervasive nature of computing. What
used to only be on mainframes in raised-floor rooms behind badge readers and
ibm.com/bcs
Executive technology report
5

PPL Abstract data types

Structured and Abstract Data Types

A structured data type is simply a composition of several elementary data types or several other structured data types. An abstract data type is basically a data type that can have the characteristics of an elementary data type or a structured data type.

Structured Data Types

A structured data type is simply a composition of several elementary data types or several other structured data types. Since there are so many types of structured data, it would be helpful to lay out the basic characteristics of structured data. Structured data types can either have a fixed or a variable number of components. Components in a structured data type can be heterogeneous or homogenous. They can be of the same type or of different types. Names can be used to identify each component in a structured data type. There are limits as to how many components can be included in a structured data type. Components in a structured data type are also organized in vectors or in dimensions.
There are also many types of operations on structured data types. A component selection operation can be done sequentially. Sequential selection happens when the accessing formula follows a base address and then an offset calculation. Linked representation selection happens when a pointer is used to identify the component through a series of chains. Components can be deleted and can be added in a structured data type. A whole data structure may be created or may be dissolved anytime. Declarations can be made on structured data types. You can declare a structured data type to be a set of integers, floating point numbers, or whatever data type you want.
There are several structured data types. Arrays are a fixed number of homogeneous components. A one dimensional array is called a vector while a two dimensional array is called a matrix. You can use arrays for data that involves several elementary data types like names and numbers. There are four types of arrays. A static array is an array with subscript ranges that are statically bound and storage locations that are statically bound as well. This means that if you utilize and array within a given function, you can not use it outside the said function anymore. Memory consumption for a static array is already predefined even before a program is run. A fixed stack dynamic array is an array with subscript ranges that are statically bound but instead of having statically bound storage locations, allocation is done during execution. This fixed stack dynamic array can only be utilized within the function where it was declared. Memory consumption is used when the program is in execution. A stack dynamic array has both its subscript ranges and its storage allocation dynamic. If your arrays are stack dynamic, this means that you can use your arrays across several functions within a program. Memory consumption for these arrays is also done during program exexution. A heap dynamic array also has both the subscript ranges and storage allocation dynamic plus you can also change them anytime during the lifetime of the array. When your arrays are heap dynamic, this means that you can practically change your arrays anytime you want, even while the program is running. Memory allocation for the arrays is also done during execution.

The illustration shows a vector and a matrix. One dimensional arrays are called vectors. Two dimensional arrays are called matrices.
Records are a fixed number of heterogeneous components. Records can also be called fields. Records utilize linear representation using a single block of sequential memory. Records also use identifier names or field names for their components.
Union types are structured data types that are capable of storing different data type values at different times during program execution. A union type is most useful when one needs a data object that can be interpreted in a variety of ways.
Lists are basically structured data types that are composed in an ordered sequence of data structures. It can vary in length and the components may be heterogeneous or homogeneous. Every node on a list is called a list item. List items can either be another list or an element called an atom with a value.
Sets are structured data types that are composed of an unordered collection of distinct values. Sets are usually stored as bit strings. A bit value of 1 represents the presence of an element while a bit value of 0 represents the absence of an element. Operations on sets include membership, insertion and deletion, unions of sets, intersections of sets, and differences in sets. Operations on sets are implemented using the Boolean values AND, OR, and NOT.
Files are structured data types that have a lifetime that is greater than the time of the program creating it. They can be represented on a secondary storage device. Sequential files are basically files that are composed of a linear sequence of components of the same type. They can vary in length wherein the components can be added, deleted, read, opened, written on, closed, or whatever action need be done to it. Direct access files are files where any single component may be accessed at random. A key is used to select a component where read and write operations can be done. Indexed sequential files have characteristics of sequential files and direct access files. A key is used to select a component and the next action can choose the next component in a sequence.
Abstract Data Types
An abstract data type is basically a data type that can have the characteristics of an elementary data type or a structured data type. In fact, in most programming languages, a programmer is the one who defines what an abstract data type will be. Abstract data types are abstract mainly because they are independent of any sort of definition or implementation. There is absolute freedom on what the programmer wants to do with a data type classified as abstract. For example, a programmer may want to create an associative array. It is basically an array composed of keys associated with one value. An associative array has features of an enumeration and features of an array, features of an elementary data type and features of a structured data type, respectively. There are many more abstract data types that can be created like complex numbers, priority queues, etcetera…

Tuesday, September 15, 2009

NOTES ON SEQUENCE CONTROL

Programming Language
SEQUENCE CONTROL


Contents

n Introduction
n Sequence Control Structures
n Sequencing with Arithmetic Expressions
n Sequencing with Non-Arithmetic Expressions
n Sequence Control between Statements

Introduction

n Program control involves
n Sequence control
n control of the order of execution of the operations

n Data control
n control of transmission of data among subprograms of a program


Sequence Control Structures

n Structures used in expressions
n precedence rules and parenthesis
n Structures used between group of statements
n conditional and iteration statements
n structures used between subprograms
n subprogram calls

n Implicit control vs. explicit control
n Implicit control
n defined by the language and not modified until user redefine it
n Explicit control
n programmer uses to redefine implicit control sequence (parenthesis)


Sequencing with arithmetic expressions(1/5)

n Prefix Notation
n Operators come first, then the operands
n e.g. (a + b) * (c - a) => * + a b - c a
n No ambiguity and no parenthesis needed
n Number of arguments for an operator must be known a priori
n Relatively easy to decode using stack mechanism
n Postfix notation
n An operator follows its operands
n e.g. (a+b) *(c-a) => a b + c a - *
n No ambiguity and no parenthesis needed
n Relatively easy to decode using stack mechanism

Sequencing with arithmetic expressions(2/5)

n Infix notation
n Only suitable for binary operations (Thus used with prefix)

n For more than one infix operator, it is inherently ambiguous

n Parenthesis is used to explicitly annotate the order

Sequencing with arithmetic expressions(3/5)

n Implicit control rules
n Hierarchy of operations (precedence) e.g. Ada
n **, abs, not : Exponential absolute negation
n * / mod : Multiplication, division,
n + - : Unary addition and subtraction
n + - & : Binary addition and subtraction
n = < > : Relational
n and or xor : Boolean operatins
n Table 6.2 pp245
n Associative
n left-right associativity (+, -, others)
n right-left associativity (exponential)

Sequencing with arithmetic expressions(4/5)

n Issues in Evaluating Expressions
n Uniform Evaluation rules (eager and lazy)
n Eager
n evaluate the operands as soon as they appear (parallel processing SNOBOL)
n Lazy Evaluation
n Delay evaluation of operands as late as possible (LISP)

foo( x )
{ ...
if ( a > 0 )
a = x;
else a = a + 1;
}

foo( b/a );

Sequencing with arithmetic expressions(5/5)

n Issues in Evaluating Expressions
n Side effects
n a * foo(x) + a; say a= 1; foo(x) generates 3
n if each term is evaluated 1 * 3 + 2 = 5
n if a is evaluated only once 1 * 3 + 1 = 4
n if evaluate foo(x) first 2 * 3 + 2 = 8
n Error Condition
n No solution other than exceptional statements
n Short-circuit expression
n Use the characteristics of “and” or “or” operation

a b - a is true b is not evaluated
a && b - a is false b is not evaluated
e.g.
b = 9;
if ( a = 4 b = 3 )
printf (" a = %d b = %d\n");

Sequencing with Non-arithmetic expressions(1/3)

n Pattern Matching
n Pattern matching operation
n An operation matches and assigns a set of variables to a predefined template

e.g. (palindromes)
A -> 0A0 1A1 0 1
matches 00100 -> 00A00 -> 0A0 -> A
applied term rewriting 00A00 is a term rewrite of 00100

n term rewriting
n A restricted form of pattern match

e.g. Given string a1a2a3a4 and α -> β.
if α = a3 then a1a2βa4
we say a1a2βa4 is term rewrite of a1a2a3a4

e.g.) in ML
fun fact(1) = 1
fact(N:int) = N * fact(N - 1);
fun length( nil ) = 0
length( a :: y) = 1 + length( y )

Sequencing with Non-arithmetic expressions(2/3)

n Pattern Matching (continued)
n Unification and substitution
n In Prolog, Database consists of facts and rules
n Substitution
n replacement of a string to another one
n Unification
n A pattern match to determine if the query has a valid substitution consistent with the rules and facts in the database


Fact : ParentOf( Ann, John) ParentOf( Sam, Ann)
Fact : ParentOf( Tom, John)
Query : ParentOf( x, John)
Þ X = Ann, x = Tom
Rule : GrandOarentOf( X,Y) :- ParentOf(X,Z), ParentOf(Z,Y)
then query : GrandParentOf (x,John) => x = sam

Sequencing with Non-arithmetic expressions(3/3)

n Backtracking
n Backup to the previous subgoal that matched and try another possible goal for it to match when current subgoal is failed

Sequence Control Between Statements (1/9)

n Basic statements
n Statements that apply operations to data objects
n Considered as a unit of step
n e.g. : assignment operations, subprogram calls, input/output statements
n Statement Level Sequence Control
n Composition
n Statements may be placed in a textual sequence and be executed in order
n Alternation
n Two Sequences may form alternatives and either one is executed
n Iteration
n A sequence of statement are executed repeatedly, zero or more times

Sequence Control Between Statements (2/9)

n Explicit Sequence Control (1/3)
n Goto statement (1/2)
n Unconditional goto
n Transfers control to the labeled statement
n Ex) goto NEXT

n Conditional goto
n Transfers control to the labeled statement only if the specified condition holds.
n Ex) if A=0 then goto NEXT



Sequence Control Between Statements (3/9)

n Explicit Sequence Control (2/3)
n Goto statement (2/2)
n Advantages
n Direct hardware support for efficient execution
n Simple and easy use and easy understanding for low level programmers
n May simulate any control structure
n Problems
n Leading unstructured programming (no goto in ML)
n Superfluous any program with goto can be translated into another one w/o goto
n Undefined control with nested structure


Sequence Control Between Statements (4/9)

n Explicit Sequence Control (3/3)
n Break Statement
n Control to move forward to an explicit point at the end of given control structure
n That is, exit the immediately enclosing while, for, or switch statement

While (a > b)
{
A;

if ( k > 0 ) break;
B;

}



Sequence Control Between Statements (5/9)

n Structured Programming Design
n Structured program is
n A program that contains no GOTOs

n Structured programming emphasizes
n Hierarchical design of program structure with the composition, alternation, and iteration
n Use structured sequence control that represents hierarchical design
n Textual sequences corresponds to the execution sequence
n Unique purpose group of statements then it is copied


Sequence Control Between Statements (6/9)

n Structured Sequence Control (1/4)
n Control statements that only contains one-in one-out control sequences (no goto in ML)
n Compound statement
n A sequence of statements that may be treated as a single unit in construction of large one
n Conditional statement
n Expresses alternation of two or more statements, or optional execution of a single statement
n Ex) IF statement, CASE statement
n If statements are implemented using the usual hardware supported branch and jump instruction
n Case statements are implemented using a jump table to avoid the testing of the same variable
n Jump table : A vector whose components are unconditional jump instructions

Sequence Control Between Statements (7/9)

n Structure Sequence Control (2/4)
n Iteration Statement (1/2)
n Simple repetition
n Repeat a fixed number of times
n Ex) perform BODY K times (COBOL)
n Repetition while condition holds
n Reevaluate the condition each time after BODY
n Ex) While test do BODY
n Repetition while incrementing a counter
n Initial value, final value, and the increment
n Ex) for l := 1 step 2 until 30 do BODY
n Indefinite repetition
n Used when the exit condition is complex and hard to express
n In C, all 4 forms can be written by for statement


Sequence Control Between Statements (8/9)

n Structure Sequence Control (3/4)
n Iteration Statement (2/2)
n Advantages
n Easy to debug, understand, and verify
n Disadvantages
n Multiple exit loops
n Can be replaced with “exit” in ADA or “break” in C., but PASCAL goto must be used in the for loop
n Do-while-do
n The condition is checked in the middle of the loop
n Exceptional conditions
n Unexpected end-of-file, subscript range error, bad data…
n Ex) raise statement in ADA à raise BAD DATA


Sequence Control Between Statements (9/9)

n Structure Sequence Control (4/4)
n Proper program
n Formal model of control structure, as a flow chart which;
n Has a single entry arc
n Has a single exit arc,
n Has a path from the entry arc to each node and from each node to the exit arc
n Prime program
n A proper program that cannot be subdivided into smaller proper programs
n Composite program
n A program that is not a prime
n The Structure theorem
n Bohm and Jacobini (1966)
n Any prime program could be converted into tone using only while and if statements called a well-structured program