• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Infosec policies to appsec standards   ed final
 

Infosec policies to appsec standards ed final

on

  • 329 views

Part 1 of 2-part series on InfoSec policies to AppSec controls

Part 1 of 2-part series on InfoSec policies to AppSec controls

Statistics

Views

Total Views
329
Views on SlideShare
329
Embed Views
0

Actions

Likes
0
Downloads
6
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • FYI - Holodeck won Cool vendor award in 2004
  • Cia difft for
  • Typical InfoSec controls are based on implementation and configurationRoll out an “out of the box” anti-virus solutionImplement and configure a firewall to only allow certain IP addressesConfigure Web server to not display sensitive information about the web server and applications running on top of itEnable encryption in certain database storesApplication Security controls are much more “activity” basedThere is no GUI or features/functionality to check off or select:Enable SSLSanitize all inputDevelopment teams either need to be security domain experts or procedures have to be very prescriptive
  • Same thing here as the last slide. Gather the data and direct it to a DEV team that has bought in to the security requirement as evidenced by their investment in training.
  • Supporting Points:•71% of developers feel security is not adequately addressed during the software development life cycle. And half (51%) of the security respondents feel the same way. •30% of development respondents say they build security during the post-launch phase of the software development life cycle, and 43% of developers say they fix bugs during the launch phase of the software development life cycle.•Only 13% of security respondents feel that code-induced threats present a greater risk than any human factor threat.
  • Supporting Points:•Over half (51%) of developers and over half (51%) of security personnel have no training in application security.•Nearly half (46%) of security respondents and just over half of developers (51%) say they predominantly use homegrown solutions to remediate vulnerable code.•Close to half (46%) of security folks, along with 42% of development respondents say the major attack methodology in breaches over the past 24 months is SQL injection.•54% of developers feel fixing bugs and patching applications is a significant drain on their company’s time and budget.
  • Supporting Points:•71% of developers feel security is not adequately addressed during the software development life cycle. And half (51%) of the security respondents feel the same way. •30% of development respondents say they build security during the post-launch phase of the software development life cycle, and 43% of developers say they fix bugs during the launch phase of the software development life cycle.•Only 13% of security respondents feel that code-induced threats present a greater risk than any human factor threat.
  • TeamMentor:Secure SDLC Best Practices: A general reference for all SDLC secure application development best practices for all phases -- from design and architecture, through development, testing and deployment. This complement a training program by providing learning at the time of need, i.e., an on-the-job reference guide. RemediationA reference for the technical information needed to remediate software vulnerabilities found by scanners and manual assessments. TM allows easy searching and filtering to find the specific information needed in the language being used. This complements Static and Dynamic Analysis Security TestingPolicy Translation A central place that allows easy access to secure coding standards for developers. Information needed for a given task is easily accessible -- from the policy information to the technical content needed to implement the policy. Customers can put their policies in TM and controls to SI-provided technical information. This can also be easily customized by the customer or SI (on their behalf.) This serves as a translation activity between information security policy and secure SDLC activities for members of the development team. 

Infosec policies to appsec standards   ed final Infosec policies to appsec standards ed final Presentation Transcript

  • Effective Application Security Risk Management: From Policy to Standards Ed Adams Security 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
  • About Security Innovation• 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 Create Secure Applications – STANDARDS – TRAINING – ASSESSMENT
  • 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 SecurityRole Based Receptionist, IT • Architect, Developer, Tester Manager, etc • Application Roles and PrivilegesHow to Rollout and Rollout of web application firewall and secureImplement configuration of servers, development best practices databases, anti-virus, • Application Authentication checks communications, • Secure Design components certificates, etc. • Attack surface reduction • Code hardening • Data Encryption • Input validationExpertise IT networking, database • How applications interact with environmentNeeded to and computer/OS • How applications function and fail with respectImplement configuration skills 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• 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 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 Other Standards Selected Coding Practices Requirement (Partial List)Confidentiality SOX, HIPAA, ISO - Appropriate use of strong encryption for data in databases. 27002,, GLBA, - Encrypting confidential data in memory. No custom or untrusted encryption routines FFIEC, Basel l I, One secure coding activity yields - Encrypting data in motion, especially for wireless transmissions. CA SB 1386, FIPS 199, NIST leverage across security controls - Masking confidential data that needs to be viewed in part in 6 different standardsData integrity SOX, ISO 27002, - Robust integrity checks to prevent tampering with data. HIPAA, GLBA, - Input validation and comprehensive error handling to prevent injection attacks, privilege FIPS 199, NIST escalation, and other hacking techniques. - Output encoding. Use of least privileges. - Hashing for confidential data that needs to be validated (e.g. passwords)Authentication SOX, ISO 27002, - Support for strong passwords & two-factor authentication where appropriate.and access HIPAA, II, NIST - Role-based access control and revocation of rights, with clear roles mapped to permissions.control SP - Locked down file access and database roles. No guest accounts. - Passwords and encryption keys encrypted before storage and transmission.Logging and SOX, ISO 27002, - Detailed audit trails of users accessing data and resources.auditing HIPAA, SB 1386, - Detailed logging of systems that process sensitive data, including shutdowns, restarts and NIST SP unusual events. No confidential data exposed in logs. - Event logs and audit trails available only to system admins and protected from unauthorized modifications.
  • 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• 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
  • Organization Structure for Security• Information Security (CISO) • Security Knowledge High• IT Risk Management • Application Business Logic Low• EIRM• Global Info Sec (GIS) Vulnerability Assessment &• IT GRC Management Security Champions (usually 1 per dev team) Army of Developers • Security Knowledge Low • Application Business Logic High
  • The Organizational Disconnect• 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”
  • Policy Writers Assume Dev Teams are Security Experts• 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?
  • 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. * The Ponemon Institute, “Application Security Maturity” 2012
  • Security and Development Hand-in-Hand State that there is little or no collaboration between your organization’s application development and security teams * The Ponemon Institute, “Application Security Maturity” 2012
  • Has your organization deployed an AppSec training program?40% 37% 37% 36%35%30%25% 23% 22%20% 15%15% 14% 11%10%5% 4% 1%0% Yes, fully deployed Yes, partially deployed No, but we plan to No Unsure deploy in the next 12 to 24 months Security Developer Where would they have learned proper secure coding techniques? * The Ponemon Institute, “Application Security Maturity” 2012
  • 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
  • Good, Better, Best – SQL Injection Policy✔ MINIMUMBuild web applications that defend against SQL injection attacks✔✔ BETTERBuild web applications that defend against SQL injection attacks bysanitizing all user input✔✔✔ GOODBuild web applications that defend against SQL injection attacks bysanitizing all user input using this approved sanitization routine✔✔✔✔ EXCELLENT…..plus – Software Developers do X – Software Testers do Y
  • Good, Better, Best – Protect sensitive data✔ MINIMUMProtect sensitive data✔✔ BETTERProtect sensitive data by using this approved encryption✔✔✔ GOODProtect sensitive data by using this approved encryption in databasesthat 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 theirpassword monthly✔✔✔ GOODEmploy a strong password policy by requiring users to change theirpassword monthly and require mixed alpha-numeric and at least onespecial character✔✔✔✔ EXCELLENT….plus – 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 theOWASP Top 10 “CSRF Cheat Sheet”✔✔✔ GOODCreate software applications that are resilient to CSRF attacks by using theOWASP Top 10 “CSRF Cheat Sheet” and implement a language-appropriate framework✔✔✔✔ EXCELLENT….plus – Use challenge-response – QA check reference headers
  • Inadequate, Real World Example: Application Pen Test• 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: 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
  • Insufficient, Real World Example: Data Security• 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: Security Code Review• 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: Authentication• 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 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• 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
  • 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 apreview of the content Filters allows users to isolate all or selected assets for a specific technology, category, p hase or type. Guidance Views allow Clicking the title opens users to quickly locate all the full document 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 Solutionsfrom 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 Contact Professional Services eadams@securityinnovation.com – Application Assessment – SDLC Optimization & Compliance getsecure@securityinnovation.com