Infosec policies to appsec standards ed final

Effective Application Security Risk Management:

From Policy to Standards

Ed AdamsSecurity Innovation, Inc.

About Edward Adams

• Ponemon Institute Fellow

• 20+ years of experience in Software Quality space

• Board of Directors for NAISG and ISSECO

• Contributor to New England Cable News, CSO Magazine, SC Magazine, CIO Update, Investor’s Business Daily, Optimize and CFO Magazine

• Maintains a blog with CSO Magazine

• Engineer by trade

2

• Authority in Application Security– 10+ years of research and assessment

– Security testing methodology adopted by Microsoft, Adobe, Symantec, SAP

– Authors of 8 books

• Helping Organizations CreateSecure Applications

– STANDARDS

– TRAINING

– ASSESSMENT

About Security Innovation

Agenda

Application Security (AppSec) policy and how it differs from information security policy

• Mapping AppSec to compliance, customer,and legal requirements

• Common disconnects between policy writers and development teams

• Examples of good and bad policy controls

• Working with Development and IT Teams to implement AppSec policies

The World is Flat: Network-Centric View of Security

The CIA Triad – Application vs. Information Security

• Both have policies, standards, procedures

• Information Security revolves around the famous CIA triad

– Maintain the confidentiality, integrity, and availability of information stored in networks and data communications infrastructure

• For any software to be considered secure it must conform to these these broad and high level characteristics

– Vague industry standards that integrates these three security characteristics in an identifiable and auditable manner for software

– Software applications access information unencrypted, so policy around protection has to be even more prescriptive

InfoSec versus AppSec

Information Security Application Security

Role Based Receptionist, IT Manager, etc

• Architect, Developer, Tester• Application Roles and Privileges

How to Implement

Rollout and configuration of servers, databases, anti-virus, communications, certificates, etc.

Rollout of web application firewall and secure development best practices

• Application Authentication checks• Secure Design components• Attack surface reduction• Code hardening• Data Encryption• Input validation

Expertise Needed to Implement

IT networking, database and computer/OS configuration skills

• How applications interact with environment• How applications function and fail with respect

to security• Software development skills w/ security overlay

Information vs. Application Security Control – ExampleProtect Sensitive Information

• Network Security Control– Enable SSL on the web server– Don’t transmit sensitive data via IM chats

• Actually a policy statement in PCI-DSS

• Database Security Control– Configure DB server so sensitive data stores are encrypted

• Physical Control– Shred documents that contain sensitive data

• Application Security– Encrypt sensitive data during transmission– Web facing applications must be resilient to SQL injection attacks

The AppSec statements are not “1-degree” actionable

Agenda

• Application Security (AppSec) policy and how it differs from information security policy

Mapping AppSec to compliance, customer,and legal requirements




The Corporate Application Compliance Frameworkaligning development with management policies

The Corporate Application Compliance Framework:Top Level: Executive Management

• Enterprise Risk Management, HR, and Legal define the global scope, objectives and requirements for corporate governance

– applicable legislation (Sarbanes-Oxley, HIPAA, California SB 1386)

– industry standards (ISO 2700x, FISMA/NIST standards)

– compliance mandates (PCI DSS)

– legal and human resources requirements (data privacy laws)

– the potential impacts of security breaches

– the costs of security breaches and attacks

The Corporate Application Compliance FrameworkMid-level: GRC & Security Groups

• ERM, GRC & Security teams add detail to create policies– high-level guidelines for operational security and compliance activities– can be contextualized for specific business units and functional roles

• Typical tasks include:– studying the applicable regulations and standards

– conducting a threat assessment to determine the security breaches potentially most damaging to the enterprise

– classifying data assets to define levels of data sensitivity

– defining concrete application security objectives

• Ideally the policies developed will be specific enough to guide the operational teams

– in practice, reaching the right level of specificity can be challenging

The Corporate Application Compliance FrameworkBase Level – functional practitioners

• Security & Compliance teams define specific development processes, coding practices, and procedures for documenting compliance documentation procedure

– ensures they’re relevant to local requirements and technology, and consistent with corporate security and compliance policies

– should address regional and business-unit specific regulations and the technologies used by each team

• Contextualizing policies for each team can be a labor-intensive and deeply technical process

– But the effort is justified and saves a TON of time long-term

– The more specific and practical the guidance, the more successful the team will be in with respect to compliance and risk reduction

Mapping Application Security to Compliance

High-Level Requirement

Other Standards (Partial List) Selected Coding Practices

Confidentiality SOX, HIPAA, ISO 27002,, GLBA, FFIEC, Basel l I, CA SB 1386, FIPS 199, NIST

- Appropriate use of strong encryption for data in databases.- Encrypting confidential data in memory. No custom or untrusted encryption routines- Encrypting data in motion, especially for wireless transmissions.- Masking confidential data that needs to be viewed in part

Data integrity SOX, ISO 27002, HIPAA, GLBA, FIPS 199, NIST

- Robust integrity checks to prevent tampering with data.- Input validation and comprehensive error handling to prevent injection attacks, privilege escalation, and other hacking techniques.- Output encoding. Use of least privileges.- Hashing for confidential data that needs to be validated (e.g. passwords)

Authentication and access control

SOX, ISO 27002, HIPAA, II, NIST SP

- Support for strong passwords & two-factor authentication where appropriate.- Role-based access control and revocation of rights, with clear roles mapped to permissions. - Locked down file access and database roles. No guest accounts.- Passwords and encryption keys encrypted before storage and transmission.

Logging and auditing

SOX, ISO 27002, HIPAA, SB 1386, NIST SP

- Detailed audit trails of users accessing data and resources.- Detailed logging of systems that process sensitive data, including shutdowns, restarts and unusual events. No confidential data exposed in logs.- Event logs and audit trails available only to system admins and protected from unauthorized modifications.

One secure coding activity yields leverage across security controls in 6 different standards

Mapping Application Security to Compliance

• Most regulations, frameworks, and compliance mandates revolve

around same key, best practices for secure development– Simple tools like spreadsheets can help you organize these

with controls for rows and activities for columns

• Repeatable SDLC that integrates key security and compliance activities:

– Ensures future requirements will have little impact on existing efforts– Allows you to maintain a “big picture” view to software development and IT

teams

• Secure development has benefits beyond compliance

– Audit costs and “re-do” expenses dramatically reduced– over 70% of all exploits take advantage of known

and common vulnerabilities

Agenda



Common disconnects between policy writers and development teams



Organization Structure for Security

Vulnerability Assessment & Management

Security Champions(usually 1 per dev team)

Army of Developers

• Security Knowledge High• Application Business Logic Low

• Security Knowledge Low• Application Business Logic High

Softw

are

Dev

elop

men

t Org

aniz

atio

n(s)

• Information Security (CISO)• IT Risk Management• EIRM• Global Info Sec (GIS)• IT GRC

The

“Sec

urity

” tea

m

• IT/GRC organizations historically focused on network/endpoint security

– All of the sudden, developers and SDLC are “in scope”

• Security, GRC, and Development/IT teams…..– Speak different languages – Have different perspective on what policies and procedures are in place– Security Teams don’t typically have a development background – Developers often don’t know how to properly address problems

• Policy writers call out general requirements like:– “Must develop applications according to industry best practices”

• Ummmm…where do I find these?

– “Must protect cardholder data”

The Organizational Disconnect

• Software developer ≠ security expert– Expectation is that developers can understand and implement security policies

– Secure Software Development is a completely different animal

• Where do they go to get this information?– An old book?

– An internal security champion/expert?

• Lots of misinformation out there– Mostly by non-practitioners and others that don’t understand functionality

trade-offs, ship/release pressures, risk management, etc.– What search results can be trusted?

Policy Writers Assume Dev Teams are Security Experts

Is Security Integrated into the SDLC?

State they either have no process (like an SDLC) at all, or an inefficient ad-hoc process for building security into their applications.

* The Ponemon Institute, “Application Security Maturity” 2012

Do Organizations Practice Fixing Vulnerable Code?

State there is no formal mandate in place to remediate vulnerable application code.


Security and Development Hand-in-Hand

State that there is little or no collaboration between your organization’s application development and security teams


Has your organization deployed an AppSec training program?


Yes, fully deployed Yes, partially deployed

No, but we plan to deploy in the next 12

to 24 months

No Unsure0%

5%

10%

15%

20%

25%

30%

35%

40%

22%23%

15%

36%

4%

11%

37%

14%

37%

1%

Security Developer

Where would they have learned proper secure coding techniques?

Agenda




Examples of good and bad policy controls


Good, Better, Best – SQL Injection Policy

✔ MINIMUMBuild web applications that defend against SQL injection attacks

✔✔ BETTERBuild web applications that defend against SQL injection attacks by sanitizing all user input

✔✔✔ GOODBuild web applications that defend against SQL injection attacks by sanitizing all user input using this approved sanitization routine

✔✔✔✔ EXCELLENT

…..plus– Software Developers do X– Software Testers do Y

Good, Better, Best – Protect sensitive data

✔ MINIMUM

Protect sensitive data

✔✔ BETTERProtect sensitive data by using this approved encryption

✔✔✔ GOODProtect sensitive data by using this approved encryption in databases that store and during transmission of sensitive data

✔✔✔✔ EXCELLENT….plus

– Architects define algorithms

– Developers never write their own crypto

– Test/QA verifies XYZ

Good, Better, Best – Strong Password Policy

✔ MINIMUMEmploy a strong password policy

✔✔ BETTEREmploy a strong password policy by requiring users to change their password monthly

✔✔✔ GOODEmploy a strong password policy by requiring users to change their password monthly and require mixed alpha-numeric and at least one special character


– Architects define authentication mechanisms– Developers implement this in code for applications– Testers verify by trying to break the requirement

Good, Better, Best – Cross Site Forgery (CSRF)

✔ MINIMUMCreate applications that are resilient to Cross-Site Request Forgery

✔✔ BETTERCreate software applications that are resilient to CSRF attacks by using the OWASP Top 10 “CSRF Cheat Sheet”

✔✔✔ GOODCreate software applications that are resilient to CSRF attacks by using the OWASP Top 10 “CSRF Cheat Sheet” and implement a language-appropriate framework


– Use challenge-response– QA check reference headers

• Policy:– “Conduct annual tests of internet facing applications”

• How to improve it– Specify the type of test, e.g., web vulnerability

scan, source code review, paper audit, etc.

– How deep should it go / What should be tested?• OWASP Top 10 vulnerabilities

– Define the key assets you are trying to protect

– Specify which attacks should be conducted• Threat modeling in advance can guide you here

Inadequate, Real World Example: Application Pen Test

Inadequate, Real-World Example: Input Validation

• Policy– “Ensure applications validate input properly and restrictively, allowing

only those types of input that are known to be correct”

– …”examples include, but are not limited to, cross-site scripting, buffer overflow errors, and injection flaws.”

– “…see http://www.owasp.org for more”

• How to improve it– Use this input sanitation routine <URL>– Validate Input from all sources For Type, Length,

Format, and Range– Identify all source of input and verify validators

have been used to check input

– User type-safe parameters and stored procedures

• Policy– “Ensure applications make use of secure storage and transmission of

data as required by confidentiality, integrity and availability needs.”

• How to improve it– For data stored in databases, use a NIST-approved

encryption of at least 256-bit strength, e.g., AES-256

– For transmission of sensitive data, use IEEE certified public-key encryption, e.g., NTRU (IEEE 1363.1)

– Encrypt Sensitive Data in Configuration Files

Insufficient, Real World Example: Data Security

• Policy– “Conduct code-level security reviews with peers for all new or

significantly modified applications; particularly, those that affect the collection, use, and/or display of confidential data.”

– “…use threat modeling to prioritize”

• How to improve it– Specify what to look for in the code review

• What data types/forms must be encrypted/masked?• Use code analysis tool to scan for common vulnerabilities• Verify no user input is reflected on subsequent web

pages (potential XSS issue)

– Threat Modeling• Prioritize assets the application touches/manages• Identify worst case scenarios a development team can test against• Offer references to threat modeling resources, e.g.,

http://www.microsoft.com/security/sdl/adopt/threatmodeling.aspx

Insufficient, Real World Example: Security Code Review



• Policy– “Ensure applications processing data properly authenticate users

through central authentication systems where possible.”

– “If additional functionality is needed, coordinate development with Information Technology Services”

• How to improve it– Here is our approved authentication library <URL>– Remove ambiguity

• “coordinate with ITS”– Rather, obtain written exception for using any authentication

mechanism not explicitly approved by InfoSec Office

• “where possible”

Insufficient, Real World Example: Authentication

Insufficient, Real World Bad Policy: SQL Injection

• Policy– “SQL Injection vulnerabilities must be prevented”

– See OWASP SQL_Injection_Prevention_Cheat_Sheet for recommendations

• How to improve it– Use Parameterized SQL statements and stored

procedures.

– Use white-listing to constrain user input

– Use company-approved sanitation library, found here <URL>

Agenda





Working with Development and IT Teams to implement AppSec policies

Make Policies Complete, Accurate, Visible

• It is important to have policies in place that require security in the application development and acquisition process

– However, if internal procedures are not modified to support the policy, impact is limited

• Make policies complete and accurate– Ensure policy writers have basic understand of secure software

development, roles, activities, etc.– Work with a security champion to ensure translation is accurate/complete– Ensure high-risk applications have the most explicit guidelines first

• Make Policies Visible– Where do they reside?– How is the development team made aware of security policies?– How does the development team access security policies?– How do you get feedback on effectiveness and explicitness of standards?

Structure your Teams for Success

• Architects & Product Teams– Designate person/team to review applications for security requirements – Can be members of development knowledgeable about InfoSec practices, or

members of InfoSec with specific knowledge of secure development

• Development Teams– Should be trained in secure coding practices

• Ideally for languages applications are being developed in

– At minimum, should have one or two senior developers/architects to conduct code reviews and coach others

• These experts can establish secure coding "best practices” for rest of team

• Test Teams– Should have key members who are trained in developing cases that test

availability, confidentiality and data integrity• These experts can create standardized, detailed test plans for rest of team

• Security/GRC Teams– Should have basic knowledge of dev. team roles and AppSec best practices

Application Security Policy – Key Components

• Describes contextual, technical guidelines on how security should be integrated within the SDLC

– By phase, role, technology, application type– Leverages internal secure development champion(s) for input

• Maps to compliance mandates

• Considers criticality of application and data– requirements, activities and level of detail needed will differ

• Has clear exception policy– What if minimum standards can’t be met? What is considered

acceptable? Who approves?

• Includes internally built and third party applications

• Reflects current maturity and secure development skills– The more skilled, the less explicit you need to be with policies

TeamMentor in Practice – SQL Injection

Search Box for text

searching

Click the [+] to see a preview of

the contentFilters allows

users to isolate all or selected assets for a

specific technology,

category, phase or type.

Clicking the title opens the full

document

Guidance Views allow users to

quickly locate all items of a specific

genre

SQL Injection:

TeamMentor to Map InfoSec Policies to Implementation

Import your InfoSec Policies and map to specific

development guidance

Application Security Solutions from Security Innovation, Inc.

Computer Based Training– 45 Technical & Awareness courses– Secure Design, Coding, Testing– .NET, Java, C/C++, C#, PHP, Mobile, OWASP, PCI, Database

Secure Development Standards– Aligns development activities to policies– 3,500 secure development best practices for OWASP, PCI, Web Services– Create dedicated guidance views for your security policies– Meets PCI requirements 6.3, 6.5 and 6.6 out of the box

– Application Assessment – SDLC Optimization & Compliance

Professional ServicesContact

[email protected]

[email protected]

mailto:[email protected]

mailto:[email protected]

Infosec policies to appsec standards ed final

Documents

corporate security

security characteristics

operational security

grc security teams

costs of security breaches

security innovation

compliance policies

application roles