The Security Development Life Cycle

(1)

Test and Verification Solutions

The Security Development Life Cycle

Delivering Tailored Solutions for Hardware Verification and Software Testing

Intelligent Testing

(2)

(3)

The Security Testing Lifecycle

Review SDLC Process

Review Policy _{Review Standards}

Review Requirements Create/Review _Design Create/Review Models

Review Code Code Walkthrough Unit & System Test Penetration

Test

Config. Mgt. Review

Unit & System Test

Acceptance Test

Change Health Operational Regression

Before Development

Definition & Design Development

Deployment

(4)

Waterfall / V-model & Security



Positive: Good documentation up front helps threat

modelling; Traditional approach for experienced

security professionals; More time for security

analysis and planning before delivery.



_{Negative: Architectural decisions taken too early;}

Tendency towards ‘big-bang’ testing at the end of

development; Change control issues; Last-moment

rush to fix security issues leads to ineffective

work-around; Maintenance difficulties.

(5)

Agile & Security



Positive: Easier to fix code vulnerabilities that were

written days ago than months or years ago; Abuse

cases to complement use cases; More likely to have

enough information on code, scale, performance

and security to make architectural decisions;

Better change control.



Negative: Need non-functional expertise in the

project team; Over-reliance on automation.

(6)

What is driving security?

Firewalls / IDS / IPS based upon pattern-matching ‘known bad’ REGEX

(7)

EU comprehensive reform of data protection rules

• A single set of rules on data protection, valid across the EU.

• Increased responsibility and accountability for processing personal data. e.g. Mandatory notification to the national supervisory authority of serious data

breaches as soon as possible (if feasible within 24 hours).

• A single national data protection authority in the EU country where they have their main establishment. Likewise, people can refer to the data

protection authority in their country, even when their data is processed by a

company based outside the EU. Wherever consent is required for data to be processed, it has to be given explicitly, rather than assumed.

•A ‘right to be forgotten’ will help people better manage data protection risks online: people will be able to delete their data if there are no legitimate grounds for retaining it.

• EU rules must apply if personal data is handled abroad by companies that are active in the EU market and offer their services to EU citizens.

• Independent national data protection authorities will be strengthened so they can better enforce the EU rules at home. They will be empowered to fine companies that violate EU data protection rules. This can lead to penalties of

(8)

The Cost Driver

(9)

(10)

The spending mismatch

(11)

Security Policies: Regulatory/Advisory/Informative Organizational policy

Acceptable use Risk management Vulnerability Mgt.

Data Protection

Access Control

Log aggregation and auditing Personnel security Business Continuity Physical security

Secure application development Change control e-mail

Incident response

System-specific policies:

e.g. How laptops are protected

Who has access

Issue-specific policies (aka Functional):

Auditing process

(12)

The Security Testing Lifecycle

Test

Unit & System Test Acceptance Test Change Verification Health Checks Operational Reviews Regression Tests Before Development

Deployment

(13)

Derive Negative Security Test Requirements

Misuse cases describe unintended and malicious use scenarios.

Think about how a use scenario can be maliciously exploited.

Discover potential flaws or aspects of the app that are not

well-defined.

Describe all possible, or at least the most critical use and misuse scenarios.

(14)

Security Design

Earn, never assume trust

Fail securely

Authorize after Authentication Grant least privileges Separate privileges

Get cryptography right

Always consider the users

Avoid complexity Validate at every boundary Defend in depth

Promote privacy

Mediate completely Assume secrets are unsafe Separate data & instructions

(15)

Security Models

State Machine Bell-LaPadula Clark-Wilson Information Flow Non-interference Lattice

Brewer and Nash Graham-Denning

Harrison-Ruzzo-Ullman Biba

(16)

The Security Testing Lifecycle

Review Code Code Walkthrough Unit & System Test

Penetration Test

Unit & System Test Acceptance Test Change Verification Health Checks Operational Reviews Regression Tests Before Development

Deployment

(17)

(18)

Automated scanners: How do they do that?



Crawler module: Seeded with URLs, retrieves

pages, follows links and redirects to identify all

reachable pages and input points.



Attack module: Analyses discovered URLs and input

points, then generates values likely to trigger a

vulnerability.



Analysis module: Examines responses to attacks by

(19)

What are ‘standalone’ scanners good at?



Reflected cross-site scripting (XSS)



_{Some SQL injections}



Some path traversals



Some command injections



Simple directory listings



Clear text password submission



Liberally scoped cookies



Forms with autocomplete enabled

(20)

OWASP #3 – Cross Site Scripting (XSS)

Cross-Site Scripting (XSS) attacks are a type of injection problem, in which malicious scripts are injected into the otherwise benign and trusted web sites. Cross-site

scripting attacks occur when an attacker uses a web

application to send malicious code, generally in the form of a browser side script, to a different end user.

(21)

OWASP #3 – XSS: Reflected

Reflected XSS attacks are those where the injected code is

reflected off the web server, such as in an error message, search result, or any response that includes some or all of the input sent

(22)

OWASP #3 –XSS: Stored

Stored XSS attacks are those where the injected code is

permanently stored on the target servers, such as in a database, in a message forum, visitor log, comment field, etc.

(23)

OWASP #3 – XSS Type 3 of 3: DOM-based

DOM (Document Object Model) XSS attacks execute a payload

as a result of modifying the DOM “environment” in the victim’s

The page itself (the HTTP

response that is) does not change, but the client side code contained in the page executes differently due to the malicious modifications that have occurred in the DOM environment.

(24)

OWASP #1 – Injection

• SQL (Oracle, MySQL, MS-SQL) Database injection

• Operating System (OS) command injection

• Web scripting language injection

• XPath injection

• SOAP injection

• SMTP injection

• LDAP injection

• HTTP Header injection

Occurs when an application is built upon false assumptions of trust. User input is not properly validated and commands are injected when the language interpreter treats malicious input as program instructions written by the developer.

(25)

Copyright TVS Limited | Private & Confidential | Page 25

Path traversal example

https://example.com/scripts/GetImage.aspx?file=diagram1.jpg

The Server extracts the value of the file parameter from the string. The value is appended to C:\example\images\

The file called diagram1.jpg at that location is opened. The contents of the file are read and sent to the client.

What if we placed an alternative value in the file parameter?

https://vulnerablesite.com/scripts/GetImage.aspx?file=..\..\windows\re

pair\sam

The application obtains the following path:

C:\example\images\..\..\winnt\repair\sam

The two traversal sequences step up the directory to the root.

C:\winnt\repair\sam

(26)

Automated scanners: What goes wrong?



Rudimentary input validation not probed for bypass



Vulnerability triggered but result doesn’t match

expected signature



Broken access controls do not have a standard

signature



Scanners don’t understand the meaning of changing

parameters within the application



Logic flaws don’t have a standard signature



Design vulnerabilities don’t have a signature



Understanding the significance of content from

modifying session parameters (predictable sessions)

(27)

Copyright TVS Limited | Private & Confidential | Page 27

Automated scanners: What goes wrong?



Attempts at Artificial Intelligence generate massive

volumes of false positive and false negative results



A large proportion, but not all, low-hanging fruit

will be detected by automated scanners



Every Web Application is different, much more than

network infrastructures



_{Syntax versus semantic meaning of content}



Improvisation



Intuition (multi-stage process, sequence changes,

crafted changes to multiple parameters)

(28)

Security Testing Tools

/ IPS based upon pattern-matching ‘known bad’ REGEX

Pentest Frameworks: Metasploit & Kali Linux Intercepting Proxy: BurpSuite Zap w3af Charles Webscarab Ratproxy

(29)

Password / Network cracker:

John The Ripper Hydra

Cain & Abel

Web server vulnerability scanner:

Nessus

Network Scanner:

Nmap Netcat

(30)

Sniffer:

Wireshark Ettercap Dsniff

Wireless:

Aircrack-ng (best with Fern Wifi Cracker as a GUI interface) Kismet WifiScanner Bluetooth: Bluescanner FTS4BT BlueSpam

(31)

OSINT tools

Maltego is a program that can be used to determine the relationships and real world links between:

• People

• Groups of people (social networks) • Companies

• Organizations • Web sites

• Internet infrastructure such as: • Domains • DNS names • Netblocks • IP addresses • Phrases • Affiliations

(32)

The intercepting proxy

(33)

The Security Testing Lifecycle

Test

Unit & System Test

Acceptance Test

Change Health Operational Regression

Before Development

Deployment

(34)

OWASP #9 – Using Known Vulnerable Components

(35)

OWASP #9 – Using Known Vulnerable Components

Verizon research found 99.9% of exploited vulnerabilities were compromised more than a year after the CVE was published.

(36)

Safe journey home

(37)

Test and Verification Solutions

The Security Development Life Cycle

Delivering Tailored Solutions for Hardware Verification and Software Testing

TMS - Bristol