so#ware(security - bcs.org · gary mcgraw, ph.d., ... the software security framework ... building...

So#ware Security Professor Mark Josephs FBCS CITP

School of Compu8ng & Digital Technology

Overview • Mo#va#on for Building Security into So5ware

• Microso5’s So5ware Security Ini#a#ve

• Community-‐Developed Resources

• Maturity Model

“So5ware security is the idea of engineering so5ware so that it con#nues to func#on correctly under malicious aBack.”

McGraw, 2004

Why build security into so#ware? Reduce number and severity of exploitable so5ware vulnerabili#es

e.g. “buffer overflow” in finger service exploited by Morris worm (1988)

e.g. first public discussions of “SQL injec#on” (1998)

•  Security technologies, such as firewalls, IDS and AV, offer only par#al solu#ons (basic hygiene)

•  Penetra#on tes#ng is important but insufficient

•  Reputa#on of so5ware suppliers is at stake Bill Gates’ memo, January 15, 2002, launched Microso5's “Trustworthy Compu#ng” ini#a#ve

Over 75,000 CVE-‐Iden#fiers have been assigned to so5ware products in 15 years, but just one vulnerability in Apache Web Server poten#ally affects over 80 million ac#ve websites

“The recent explosion of Internet-‐enabled devices—known as the Internet of Things—as well as the propaga#on of so5ware-‐based func#onality in systems has led to a huge increase in the number of CVE requests we have been receiving on a daily basis.”

The CVE Team, March 21, 2016

“an overwhelming majority of security vulnerabili#es are caused by ‘buggy’ code …

less than 15 percent of all CERT advisories described problems that could have been fixed or avoided by proper use of cryptography. Avoiding design and implementa#on errors in so5ware is an essen#al part of the security landscape.”

Na#onal Research Council, 1999

“The biggest problem in computer security today is that many security prac##oners don’t know what the problem is. Simply put, it’s the so5ware!”

Viega and McGraw, 2001

“You may have the world’s best firewall, but if you let people access an applica#on through the firewall and the code is remotely exploitable, then the firewall will not do you any good (not to men#on the fact that the firewall is o5en a piece of fallible so5ware itself).”

Viega and McGraw, 2001

“Technology vendor Cisco is pushing out security updates to customers to address a cri#cal vulnerability found in its recently introduced line of FirePower firewall products. The vulnerability, according to Cisco, allows aBackers to slip malware onto cri#cal systems without detec#on. The flaw also impacts Snort, an open source network-‐based intrusion detec#on system also owned by Cisco.

Cisco alerted customers of the vulnerability (CVE-‐2016-‐1345) last week classifying it as ‘high severity’. The networking firm has released so5ware updates that address the vulnerability in Cisco Firepower System So5ware 5.4.0.7 and later, 5.4.1.6 and later and 6.0.1 and later.”

Threatpost, April 4, 2016

“ABempts to correct (patch) iden#fied security vulnerabili#es were not sufficient to prevent subsequent repenetra#ons. New #ger teams o5en found security flaws not found by earlier #ger teams, and one could not rely on the failure of a penetra#on effort to indicate that there were no exploitable security flaws.”

Faurer, 1984

“Every week there are reports of newly discovered security problems in all kinds of so5ware … teams work around the clock to deliver security fixes …

Our new design approaches need to drama#cally reduce the number of such issues that come up in the so5ware that Microso5, its partners and its customers create.

We need to make it automa#c for customers to get the benefits of these fixes. Eventually, our so5ware should be so fundamentally secure that customers never even worry about it.”

Gates, 2002

Windows Security Push In early 2002, Microso5

•  conducted 10 weeks of intensive security training •  analyzed the Windows code base

8,500 Windows engineers, plus

several thousand engineers in other parts of the company, were trained in

•  secure programming

•  tes#ng techniques •  threat modeling

Dic;onaries of Common Weaknesses and AAack PaAerns

•  Launched in March 2006 •  Latest version released December 2015

contains about 1000 types of vulnerability •  CVE is source of observed examples 2011 CWE/SANS Top 25

Most Dangerous So5ware Errors •  Educa#on and awareness

Latest version lists 504 aBack paBerns

Resources for Web Applica;on Developers and Testers

Application Security Verification Standard 3.0 October 2015

Building Security in Maturity Model •  iden#fies ac#vi#es being carried out within so5ware security ini#a#ves

•  represents a study of organiza#ons that Cigital (a leading so5ware security consultancy) has been conduc#ng since 2008

Version 6 (October 2015) involved 78 firms that have been prac#sing so5ware security for an average of four years (ranging from less than one year to 15 years)

AuthorsGary McGraw, Ph.D., Sammy Migues, and Jacob West

6

Cigital observed that the first step of a so5ware security ini#a#ve is forming a So5ware Security Group (SSG), the internal group charged with carrying out and facilita#ng so5ware security.

Size Total Smallest Median Largest

SSG 1,084 1 6 130

Satellite 2,111 0 3 400

Developers 287,006 23 1,200 35,000

112 ac#vi#es organized into 3 levels and into 12 prac#ces within 4 domains

10 | Building Security In Maturity Model (BSIMM) Version 6

BSIMM6 StructureThe BSIMM is organized as a set of 112 activities in a framework.

The Software Security FrameworkThe table below shows the software security framework (SSF) used to organize the 112 BSIMM activities. There are 12 practices organized into four domains.

The four domains are:

Governance: Practices that help organize, manage, and measure a software security initiative. Staff development is also a central governance practice.

Intelligence: Practices that result in collections of corporate knowledge used in carrying out software security activities throughout the organization. Collections include both proactive security guidance and organizational threat modeling.

SSDL Touchpoints: Practices associated with analysis and assurance of particular software development artifacts and processes. All software security methodologies include these practices.

Deployment: Practices that interface with traditional network security and software maintenance organizations. Software configuration, maintenance and other environment issues have direct impact on software security.

The 12 practices are:

Governance1. Strategy & Metrics (SM)

2. Compliance & Policy (CP)

3. Training (T)

Intelligence4. Attack Models (AM)

5. Security Features & Design (SFD)

6. Standards & Requirements (SR)

SSDL Touchpoints7. Architecture Analysis (AA)

8. Code Review (CR)

9. Security Testing (ST)

Deployment10. Penetration Testing (PT)

11. Software Environment (SE)

12. Configuration Management & Vulnerability Management (CMVM)

</>


LEVEL 2

ACTIVITY DESCRIPTION ACTIVITY # PARTICIPANT %

Identify PII data inventory. CP2.1 24%

Require security sign-off for compliance-related risk. CP2.2 29%

Implement and track controls for compliance. CP2.3 32%

Paper all vendor contracts with software security SLAs. CP2.4 37%

Ensure executive awareness of compliance and privacy obligations. CP2.5 42%

LEVEL 3

Create regulator eye-candy. CP3.1 23%

Impose policy on vendors. CP3.2 14%

Drive feedback from SSDL data back to policy. CP3.3 8%

TRAINING (T)

LEVEL 1


Provide awareness training. T1.1 76%

Deliver role-specific advanced curriculum (tools, technology stacks, bug parade). T1.5 33%

Create and use material specific to company history. T1.6 22%

Deliver on-demand individual training. T1.7 46%

LEVEL 2

Enhance satellite through training and events. T2.5 13%

Include security resources in onboarding. T2.6 19%

Identify satellite through training. T2.7 8%

LEVEL 3

Reward progression through curriculum (certification or HR). T3.1 4%

Provide training for vendors or outsourced workers. T3.2 4%

Host external software security events. T3.3 4%

Require an annual refresher. T3.4 10%

Establish SSG office hours. T3.5 5%

Governance continued...


ARCHITECTURE ANALYSIS (AA)

LEVEL 1


Perform security feature review. AA1.1 86%

Perform design review for high-risk applications. AA1.2 37%

Have SSG lead design review efforts. AA1.3 28%

Use a risk questionnaire to rank applications. AA1.4 59%

LEVEL 2

Define and use AA process. AA2.1 15%

Standardize architectural descriptions (including data flow). AA2.2 12%

Make SSG available as AA resource or mentor. AA2.3 17%

LEVEL 3

Have software architects lead design review efforts. AA3.1 8%

Drive analysis results into standard architecture patterns. AA3.2 1%

SSDL Touchpoints

CODE REVIEW (CR)

LEVEL 1


Use a top N bugs list (real data preferred). CR1.1 23%

Have SSG perform ad hoc review. CR1.2 68%

Use automated tools along with manual review. CR1.4 71%

Make code review mandatory for all projects. CR1.5 31%

Use centralized reporting to close the knowledge loop and drive training. CR1.6 35%

LEVEL 2

Enforce coding standards. CR2.2 9%

Assign tool mentors. CR2.5 26%

Use automated tools with tailored rules. CR2.6 21%

LEVEL 3

Build a factory. CR3.2 4%

Build a capability for eradicating specific bugs from the entire codebase. CR3.3 6%

Automate malicious code detection. CR3.4 4%

</>


Once you have determined where you stand with activities, you can devise a plan to enhance practices with other activities included in the BSIMM. By providing actual measurement data from the field, the BSIMM makes it possible to build a long-term plan for a software security initiative and track progress against that plan. For the record, there’s no inherent reason to adopt all activities in every level for each practice. Adopt those activities that make sense for your organization and ignore those that don’t.

In our own work using the BSIMM to assess initiatives, we found that creating a spider chart yielding a “high-water mark” approach (based on the three levels per practice) is sufficient to get a low-resolution feel for maturity, especially when working with data from a particular vertical.

One meaningful comparison is to chart your own high-water mark against the averages we have published to see how your initiative stacks up. Above, we have plotted data from the fake firm against the BSIMM Earth (all participating firms) graph. The breakdown of activities into levels for each practice is meant only as a guide. The levels provide a natural progression through the activities associated with each practice. However, it’s not at all necessary to carry out all activities in a given level before moving on to activities at a higher level in the same practice. That said, the levels we have identified hold water under statistical scrutiny. Level 1 activities (straightforward and simple) are commonly observed, Level 2 (more difficult and requiring more coordination) slightly less so, and Level 3 (rocket science) are rarely observed.

Compliance & Policy

Strategy & Metrics

Architecture Analysis

Standards & Requirements

Training

Security Features & Design

Attack Models

Configuration Mgmt. & Vulnerability Mgmt.

Code Review

Software Environment

Security Testing

Penetration Testing 0.0

0.5

1.0

1.5

2.0

2.5

3.0

Earth (78) Firm

SPIDER CHART FOR FAKE FIRM

Conclusion So5ware security •  proac#ve approach to computer security that emerged about 15 years ago

•  prac#ces built into the development life cycle •  involves so5ware architects, developers and testers, not just system administrators

•  supported by automated code review and tes#ng •  prac#sed by many organiza#ons, par#cularly Independent So5ware Vendors and Financial Services

so#ware(security - bcs.org · gary mcgraw, ph.d., ... the software security framework ... building...

Documents