secure software development

Secure Software Development

Risk-Based Security Testing

Chapter 7Rasool Jalili & A. Boorghani

Dept. of Computer Engineering

Spring 2012

Software Security 2Secure SW Development (SSD) Grad. Course (R. Jalili & M.S. Dousti) – Spring 2012

Risk-Based Security Testing


• Security testing has recently moved beyond the realm of network port scanning to include probing software behavior as a critical aspect of system behavior.

• Security testing done properly goes much deeper than simple black box probing on the presentation layer

• and even beyond the functional testing of security mechanism.

• Testers must carry out a risk-based approach, grounded in both the system's architectural reality and the attacker's mindset.

• By identifying risks in the system and creating tests driven by those risks, a software security tester can properly focus on areas of code where an attack is likely to succeed.

Security testing


• The main difference of security testing and pentest:– the level of approach and – the timing of the testing itself. – Pen-testing happens once software is complete and

installed in its operational environment. Also, penetration testing is focused outsidein and is somewhat brief.

– Security testing can be applied before the software is complete, at the unit level, in a testing environment with stubs and pre-integration.

– Should start at the feature or component/unit level, prior to system integration.


• Security unit testing carries the benefit of breaking system security down into a number of discrete parts.

• Theoretically, if each component is implemented safely and fulfills inter-component design criteria, the greater system should be in reasonable shape.

• Security testing should continue at the system level and should be directed at properties of the integrated software system.

• This is precisely where penetration testing meets security testing.

• Finally, abuse cases developed earlier in the lifecycle should be used to enhance a test plan with adversarial tests based on possible abuse scenarios.

• Security testing involves as much black hat thinking as white hat thinking.


• Traditional approaches to computer and network security testing focus on network infrastructure, firewalls, and port scanning.

• This is especially true of network and software penetration testing (application penetration testing).

• Better penetration testing approaches take architectural risks, code scanning results, and security requirements into account,

• but still focus on an outsidein perspective.• A classic outsidein paradigm focusing on firewall

placement.

From OutsideIn to InsideOut


• Problem: the perimeter is only apparent at the network/packet level. • At the level of software applications, the perimeter has all but

disappeared. • That's because firewalls have been configured (or mis-configured,

depending on your perspective) to allow advanced applications to tunnel right through them.

• A good example of this phenomenon is the SOAP protocol, which is designed (on purpose) to carry traffic through port 80 for various different applications.

• In some sense, SOAP is an anti-security device invented by software people.

• In the brave new world of Service Oriented Architecture (SOA) for applications, we should not be surprised that the firewall is quickly becoming irrelevant.

• By contrast, in an insideout approach to security, whereby software is itself subjected to rigorous risk management and security testing.


• Software security is about making software behave in the presence of a malicious attack.

• Standard software testing literature is only concerned with what happens when software fails, regardless of intent.

• Software security - Software safety =an intelligent adversary.• Most safety-critical systems (and high-assurance systems)

posit a white hat world. • Fact is, we live in a world with plenty of black hats as well, and

we need to address that (head on).• Attackers generally don't care whether a vulnerability is due to

a flaw or a bug, although bugs tend to be easier to exploit.• Design-level vulnerabilities are the hardest defect category to

handle.

What's So Different about Security?


• Different tasks to manage software security risks, such as:– Creating security abuse/misuse cases– Listing normative security requirements (and

security features and functions)– Performing architectural risk analysis– Building risk-based security test plans– Using static analysis tools– Performing security tests– Performing penetration testing in the final

environment– Cleaning up security breaches

Risk Management and Security Testing


• Do not forget: Software security is not security software.• So, SWS testing must necessarily involve two diverse

approaches:– Functional security testing: testing security mechanisms– Adversarial security testing: performing risk-based security

testing motivated by simulating the attacker's approach

• Together, these two distinct activities are a mix of white hat (security functionality) and black hat (security attack) philosophies.

• Wrong belief: liberal application and use of various security features "adding SSL“ to securing an application.

• Software security practitioners regret the over-reliance on "magic crypto fairy dust“.


• Security testing: determining who should do the testing and what activities they should undertake.

• Who?– Standard testing organizations using a traditional

approach functional security testing.– Traditional QA staff? They have more difficulty due to

the lack of expertise.1. Security tests are difficult to design, due to thinking like an

attacker.

2. Security tests do not often cause direct security exploit.

– Bottom line: Risk-based security testing relies more on expertise and security experience (not testing experience).

How to Approach Security Testing


• How: – Books; helps a lot …– White & Black box testing with/ without having access to source.

• In Black Box testing, malicious input is an effort to break the program;

• Any testing method can reveal possible software risks and potential exploits.

• However, One problem with security testing (black or white box) is the lack of it (Testing Method).

• There is no end-point for software security; even a reasonable security testing routine is just a start.

• Unfortunately, security is being sold as a product, and most defensive mechanisms on the market do little to address the heart of the problem, which is bad software.

• Any testing approach is deeply impacted by software process issues.


• The biggest problems in software security AS software takes input.

• Trust the input is a critical question that all software builders must consider.

• From buffer overflow (which involves putting too much input in too small a place) to SQL injection attack and cross-site scripting (XSS) attacks, trusting input is the common root cause.

• Carefully handling input is dominant to software security.

• If your program consumes data from "out there," you need to think carefully about who can feed and the stuff your program eats.

Thinking about (Malicious) Input


• STOMATH IS THE ROOT OF ALL DESEASES.• Attacker toolkits focus plenty of attention on input,

with a plenty of fault injection tools, re-players, and the like.

• By its very nature, penetration testing is focused on input as well

• If your program accepts input over the network, it needs to be very doubtful of what it is getting.

• Using a black-list approach (which tries to enumerate all possible bad input) will not work. Instead, software needs to defend its input space with a white-list approach.


• Testing around malicious input is a necessary but not sufficient condition.

• Security testing needs to focusing on data structures, components, APIs, program state, and so on.

• In addition to building tests around risks that remain in the system, testers should consider things like:– Sockets– Pipes– The Win32 Registry– Files– Remote procedure calls (RPCs)– Command-line arguments– ….

Getting Over Input


• Time is a critical issue; two major aspects of time to consider

• One problem is that most developers are unfamiliar with the effects of multithreading on their systems. That means they often overlook subtle time-based attacks.

• Unless a security tester thinks like a bad guy (black hat firmly on head), security testing will not be effective.


پايان

secure software development

Documents