Embed Size (px)
Citation preview
Introducing Secure Application
Lifecycle Management
A Whitepaper
Copyright 2012. SD Elements. 2
Secure Application Lifecycle Management
enables building in security from the start.
Proactive Approach
Copyright 2012. SD Elements. 3
The Current State of Defensive Controls
The application security product marketplace offers automated mechanisms to detect and block
software security flaws, such as static analysis, binary analysis, runtime testing, and web application
firewallsi. For example, dynamic testing tools can easily discover if a standard Session cookie has the
“secure” flag set to trueii. Similarly, a static analysis tool can verify whether or not the session cookie has
been configured to secure based on the framework in questioniii.
Dynamic Tools and Logic Flaws
Automated dynamic and static analysis both break down when developers choose to implement a
proprietary session management system. Perhaps more importantly, these systems cannot report on
the absence of a session management mechanism altogether. In practice, this sort of logic flaw is caught
by manual source code review or manual penetration testing, human-guided or exploited in the wild.
These techniques suffer from scalability. Few organizations can afford to perform the level of manual
testing required for their entire application portfolio. The problem is further exasperated by domain-
specific flaws or bugs such as insufficient authorization, which require not only human expertise but an
understanding of the software domain to uncoveriv. In one famous example, security researchers were
able to access “privacy-protected” photographs on Facebook without sufficient permissionv. While the
security community and security tool developers already have a strong understanding of insufficient
authorization, there is simply no practical method of detecting such a vulnerability using a completely
automated mechanism.
Detection is
Inefficient
Detective techniques
for flaws suffer from
being inefficient
versus preventative
techniques. In
software
development,
researchers have long
studied the sheer
cost-effectiveness of
planning for and
preventing defects
up-front rather than
finding and fixing
themvi. Figure 1: Cost of fixing defects in different phases of software development
1x
6x
11x
16x
21x
26x
31x
36x
Requirements/ Architecture
Coding Integration/Component
Testing
System /Acceptance
Testing
Production /Post-Release
Rela
tive
co
st
to f
ix,
base
d o
n t
ime o
f d
ete
ction
Source: NIST
Highest ROI
Where we find flaws today
Copyright 2012. SD Elements. 4
Threat Modeling
Practitioners sometimes turn to design or architecture review techniques, such as threat modelingvii, for
preventing software security defects. Some industry practitioners consider threat modeling to be a cost
efficient method of security defect preventionviii. This approach suffers even more from the issue of
scalability. Practitioners report that threat modeling without the involvement of qualified security
experts can be less effectiveix, even though there is a shortage of such expertisex.
Developer Education
Another preventative technique, developer education, seeks to empower developers with the
knowledge to write secure code. Research shows a positive correlation between education and
application security qualityxi. A single training class is a point-in-time activity: the value of the education
will diminish over time unless the developers are continuously in touch with material and are updated
on new / emerging techniques. Moreover, given the pressures of building software under strict
deadlines, software developers can forget about specific security defect due to cognitive burdenxii. Thus,
developer education is important but not sufficient for preventing application security defects.
Secure Requirements
Industry experts assert that building security in requirements is one of the best mechanisms for
preventing security issuesxiii xiv. Few resources offer comprehensive requirements on how to deal with
the range of issues defined in the Common Weakness Enumeration. Moreover, empirical data suggests
that requirement gathering techniques vary wildly between and even within organizations. Some
organizations have built secure programming guideline documents to address preventative software
securityxv. In the experience of Security Compass consultants, large static documents prove ineffective
for use in day-to-day development under time pressure.
Introducing Secure Application Lifecycle Management
Secure Application Lifecycle Management (SALM) systems seek to close the gaps in the current
detection-focused software security product market. SALM systems are the security extension of
Application Lifecycle Management products: tools designed to help manage the process of building
softwarexvi. SALM systems defines specific application security defects and their corresponding
preventative controls as relevant to a given application by rules relating to the application's underlying
properties, such as class of application (e.g. web vs. client/server), technology stack (e.g. Java EE, C/C++,
Android SDK), and regulatory drivers (e.g. PCI DSS). For example, a SALM system might define a rule
that “SQL Injection”xvii and its corresponding defensive control “bind variables in SQL Statements” are
relevant to any application that interacts with a database using SQL.
Copyright 2012. SD Elements. 5
Figure 2: Example SALM System rule
Researchers at SALM vendors continuously update the database of common software security flaws and
corresponding compensating controls tied to rules. Developers or security analysts can thus model an
application by profiling its technology stack, compliance requirements, and other properties.
Figure 3: Profiling an application
Copyright 2012. SD Elements. 6
Based on the application’s profile, SALM tools generate series of checklists of preventive controls in
various phases of the Software Development Life Cycle (SDLC).
Figure 4: Checklists at different phases of the SDLC
Each 'Task' specifies the underlying security weakness ('Problem') and
a succinct discussion of the control 'Solution'. By providing contextually
relevant Tasks, SALM systems re-enforce one of the most effective of
application security controls: developer awareness training, while
reducing the cognitive burden of remembering all relevant security
issues. The training is contextually relevant, thereby increasing its
effectivenessxviii . Where possible, the SALM system provides examples
of known-good source code in the developer's programming language.
Armed with actual solution code, junior developers do not have to
resort to source code examples posted on the Internet from unverified
sources. Moreover, by providing instructional videos on how to test for
defects, the SALM system provides contextual training of how an
attacker may exploit an underlying weakness.
The Power of Checklists
SALM systems can also benefit security-savvy developers. By providing
a reliable rules engine for tasks, SALM-produced checklists serve as
essential reminders for tasks that knowledgeable developers may
forget under the pressure of day-to-day development work. In his
Profile application
Run rules against profile
Generate security controls
Build security into
application
Figure 5: SALM Workflow
Copyright 2012. SD Elements. 7
seminal book The Checklist Manifesto, Dr. Atul Gawande studies fields such as piloting to discover why
some professions have low defect rates with respect to human safetyxix. He discovers that checklists are
a critical component, and armed with this knowledge his team of researchers pilot the World Health
Organization (WHO) safety checklist which results in a 47% drop in deaths arising from surgical
complicationsxx. In both surgery and piloting, practitioners initially resisted the idea of using checklists
because checklists seemed too simple to be effective in
helping complex domains where practitioners often pride
themselves on masteryxxi. Nonetheless, a wealth of data
continues to support the effectiveness of simple checklists
in reducing preventable defects. The challenge in the
software security domain is that checklists are often too
long and complex because they cover a large range of
known flaws such as the entire Common Weakness
Enumeration (CWE), or too short and not context-relevant
because they cover a small subset of defects such as Open
Web Application Security Project (OWASP) Top 10. Some IT
practitioners have grown weary of a “checklist approach”
to security based compliance-oriented, inflexible policy audited through checklistsxxii.SALM systems
solve this by using rules and profiling to deliver context-relevant defects and controls, and by providing a
mechanism to triage the defects through priority scores. Thus, developers who are pressed for time can
ensure they address the highest priority software security issues relevant to their application. Empirical
data suggests that as with other domains like medicine, seasoned practitioners may be skeptical about
the benefits of SALM checklists until they experience modeling an application and examine the resultant
checklists. One of the core developers of SD Elements, the market leader in SALM, was himself initially
skeptical of SALM until he saw the results:
"When I first saw it, I couldn’t see myself using the product. After I modeled a real application I was
working on, I immediately recognized that it caught a number of security issues I was either unaware of
had completely forgotten about. "
An architect at a system integration company and early adopter of SALM technology articulated his
experience:
“In our experience every dollar spent on identifying robust security requirements early on in the
development life cycle has translated into significant cost savings as well as increased productivity in the
testing and deployment of our projects.”
Industry is just starting to collect relevant data from SALM systems. One health insurance company used
SALM requirements up-front for a net new internally-developed application and received a 99% security
quality score from a popular binary analysis solution upon first submission, where only 17% of internally
developed applications even receive an “acceptable” score upon first submissionxxiii.
“In our experience every dollar spent on
identifying robust security requirements early on
in the development life cycle has translated into
significant cost savings as well as increased
productivity in the testing and deployment of
our projects.”
– Architect of System Integration Company. Early adopter of
SALM .
Copyright 2012. SD Elements. 8
Security Visibility
SALM solutions also provide visibility into application security posture. Currently, many organizations
assess application security posture by manual risk assessmentsxxiv or
testing for security through dynamic and static analysis. Consistent risk
assessments can often be difficult to deploy for information security.
One practitioner suggests, “Security is more like art; and security risks
really can’t be calculated”xxv. Approaches such as penetration testing
also have limitationsxxvi, including cost. SALM solutions detail lists of
controls for known software security weaknesses and track completion
status. Thus, security auditors can quickly ascertain if an in-house,
outsourced or Commercial Off The Shelf (COTS) application has
appropriately handled security controls by profiling the application in a
SALM solution and tracking which security controls are completed.
Early testing indicates that a comprehensive review of an application
using a SALM approach lasts approximately four hours for a security
analyst, including application profiling, interviewing developers/architects, and following-up on
outstanding unknown areas. Using this technique, security analysts can maintain an enterprise-wide
view of application security posture.
Figure 7: Enterprise dashboard
Higher-risk applications can then undergo more extensive, testing-based analysis such as penetration
tests. Security analysts can also use this global view of risk to determine which applications need more
help from security experts.
Figure 6: Progress of security tasks
Copyright 2012. SD Elements. 9
Knowing security controls up-front allows development teams to build cost estimates and prioritize
security issues alongside other priorities at project or iteration inception. Application owners can decide
to accept risks at the planning stage. Up-front discussion and risk acceptance have the benefit of side-
stepping arguments later in a development cycle and avoiding a culture of “development vs. security
people”xxvii.
Conclusions
SALM solutions offer unprecedented ability to achieve scalable, prevention-based application security.
Although detection based controls such as static & dynamic analysis are still critical components of an
overall secure SDLC, early evidence shows a clear business case for adopting a SALM solution. Data from
other domains also indicate that effective, check-list based preventative controls generated by SALM
tools can have a dramatic effect on defect reduction. Combined with the ability to provide visibility into
application security risk posture across an enterprise, SALM solutions are indispensable for reducing the
risk of common weaknesses for in-house developed and purchased software.
Copyright 2012. SD Elements. 10
About SD Elements
SD Elements is the market leader in Secure Application
Lifecycle Management. Some of the world’s most security
sensitive organizations in software development,
financial services, healthcare, and public sector use SD
Elements to bring secure applications to market faster.
Learn More.
Reach out to us to hear more.
Christopher Faciana
Director of Sales, Western Region
602-501-5249
Kevin Wirvin
Director of Sales, Eastern Region
732-284-8635
Copyright 2012. SD Elements. 11
i The 451 Group. “The Application Security Spectrum”. Accessed February 20, 2012. http://www.the451group.com/reports/executive_summary.php?id=1832 ii Open Web Application Security Project. “Application Security Verification Standard (ASVS) - V3 - Session
Management Verification Requirements”. Accessed February 20, 2012. http://code.google.com/p/owasp-asvs/wiki/Verification_V3 iii Open Web Application Security Project. “Application Security Verification Standard (ASVS) - V3 - Session
Management Verification Requirements”. Accessed February 20, 2012. http://code.google.com/p/owasp-asvs/wiki/Verification_V3 iv Software Assurance Maturity Model. “Domain Driven Security”. Accessed February 20, 2012.
http://www.opensamm.org/2011/01/domain-driven-security/ v Sydney Morning Herald. “Security experts go to war: wife targeted”. Accessed February 20, 2012.
http://www.smh.com.au/technology/security/security-experts-go-to-war-wife-targeted-20110517-1eqsm.html vi LKP Consulting Group. “The Real Cost of Software Defects”. Accessed February 20, 2012.
http://www.lkpgroup.com/Cost%20of%20Software%20Defects.pdf vii
Microsoft. “Improve Web Application Security: Threats and Countermeasures. Chapter 3: Threat Modeling”. Accessed February 20, 2012. http://msdn.microsoft.com/en-us/library/ff648644.aspx viii
Safecode. “Fundamental Practices for Secure Software Development 2ND EDITION”. Accessed February 23, 2012. http://www.safecode.org/publications/SAFECode_Dev_Practices0211.pdf ix Dhillon, D. Developer-Driven Threat Modeling. InfoQ. Accessed Februray 23. 2012.
http://www.infoq.com/articles/developer-driven-threat-modeling x Olstik, J. Information Security Skills Shortage Continues. Insecure About Security. Accessed February 23, 2012.
http://www.insecureaboutsecurity.com/2012/01/19/information-security-skills-shortage-continues/ xi Veracode. State of Software Security Report, Volume 4. Pg. 6. Accessed February 23, 2012.
http://info.veracode.com/state-of-software-security-report-volume4.html xii
Jing Xie J., Chu B., and Richter Lipford H., Interactive Support for Secure Software Development, In Proceedings of Engineering Secure Software and Systems Third International Symposium (ESSoS), February 2011, Madrid, Spain xiii
Open Web Application Security Project. “OWASP Application Security Requirements Projects”. Accessed February 23, 2012. https://www.owasp.org/index.php/Category:OWASP_Application_Security_Requirements_Project xiv
Mead, N. “Security Requirements Engineering”. Building Security In, U.S. Department of Homeland Security. Accessed February 23, 2012. https://buildsecurityin.us-cert.gov/bsi/articles/best-practices/requirements/243-BSI.html xv
Secure Coding Standards. CERT. Accessed February 23, 2012. http://www.cert.org/secure-coding/scstandards.html xvi
Wikipedia. Definition of Application Lifecycle Management. Accessed February 23, 2012. http://en.wikipedia.org/wiki/Application_lifecycle_management xvii
Open Web Application Security Project. “SQL Injection”. Accessed February 23, 2012.https://www.owasp.org/index.php/SQL_Injection xviii
Jing Xie J., Chu B., and Richter Lipford H., Why do programmers make security errors?, In Proceedings of IEEE Symposium on Visual Languages and Human-Centric Computing (VL/HCC), September 18–22, 2011, Pittsburgh, PA, USA xix
Gawande, A. The Checklist Manifesto, Metropolitan Books. 2009. xx
Gawande, A. The Checklist Manifesto, Metropolitan Books. Pg. 154 xxi
Gawande, A. The Checklist Manifesto, Metropolitan Books. Pg. 35, 157 xxii
Trow, T. Akibia. “The Checklist Approach to IT Security is Failing You”. Accessed February 24, 2012. http://www.akibia.com/blog/the_checklist_approach_to_it_security_is_failing_you xxiii
Veracode. State of Software Security Report, Volume 4. Pg. 10
Copyright 2012. SD Elements. 12
xxiv Stoneburner G., Goguen A., and Feringa A., NIST: Risk Management Guide for
Information Technology Systems, pg 8. Accessed February 23, 2012. http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf xxv
Faessler M., “Improving Security Risk Management”. Accessed February 24, 2012 http://www.webwire.com/ViewPressRel.asp?aId=138969 xxvi
Tuck Wai, C., SANS. “Conducting a Penetration Test on an Organization”. Accessed February 24, 2012. http://www.sans.org/reading_room/whitepapers/auditing/conducting-penetration-test-organization_67 xxvii
Wilander, J. “Security People Vs. Developers”. Accessed February 24, 2012. http://appsandsecurity.blogspot.com/2011/02/security-people-vs-developers.html
