T.E.N. Knowledge Base

	Enterprise Software Security: A Confluence of Disciplines (Addison-Wesley Software Security Series) by Kenneth R. van Wyk and Mark G. Graff
	Secure Coding: Principles and Practices by Mark G. Graff and Kenneth R. van Wyk
	Normal Accidents: Living with High-Risk Technologies by Charles Perrow

A vision for cyber security detection analytics  > Download Whitepaper
Organizations are in the midst of considering how Big Data can assist in their plans to detect advanced cyber adversaries. Many are starting to build Big Data infrastructure and feed it both structured and unstructured data, but few have determined exactly what they will do with the data after they have collected it. This paper outlines the vision of what to do with all this security data; a vision for detecting advanced adversaries through pairing Big Data and data science.

Quantifying the Value of Investments in Application Security  > Download Whitepaper
HP has developed an ROI process and model to quantify the business value of our application security solutions. The HP ROI model is based on first-hand research conducted with our customers and has been validated by HP customers across industry segments. This ROI process and model, along with the related customer examples, can serve as a starting point for building a business case to justify and investment in the application security solution.

Protection from the Inside: Application Security Methodologies Compared (A SANS Product Review)  > Download Whitepaper
In this review, we compare App Defender to an unnamed WAF, examining their respective preventive and detective capabilities. Where WAFs simply put up a wall in front of the application, RASP protects the application from the inside out. Its instrumentation of the runtime environment enables the mitigation of vulnerabilities without access to the source code. When tested against the WAF, App Defender caught more events, reduced false positives and improved visibility into vulnerabilities, including those weaknesses we didn’t know we had.

Internet of Things Research Study  > Download Whitepaper
Suddenly, everything from refrigerators to sprinkler systems are wired and interconnected, and while these devices have made life easier, they’ve also created new attack vectors for hackers. These devices are now collectively called the Internet of Things (IoT). IoT devices are poised to become more pervasive in our lives than mobile phones and will have access to the most sensitive personal data such as social security numbers and banking information. As the number of connected IoT devices constantly increase, security concerns are also exponentially multiplied. A couple of security concerns on a single device such as a mobile phone can quickly turn to 50 or 60 concerns when considering multiple IoT devices in an interconnected home or business. In light of the importance of what IoT devices have access to, it’s important to understand their security risk.

OWASP Application Security Guide For CISOs  > Download Whitepaper
Among application security stakeholders, Chief Information Security Officers (CISOs) are responsible for application security from governance, compliance and risk perspectives. This guide seeks to help CISOs manage application security programs according to CISO roles, responsibilities, perspectives and needs. Application security best practices and OWASP resources are referenced throughout this guide. OWASP is a non profit organization whose mission is "making application security visible and empowering application security stakeholders with the right information for managing application security risks".

IDA State-of-the-Art Resources (SOAR) for Software Vulnerability Detection, Test, and Evaluation  > Download Whitepaper       Download SOAR Matrix
The purpose of this paper, “State-of-the-Art Resources (SOAR) for Software Vulnerability Detection, Test, and Evaluation,” is to assist Department of Defense (DoD) program managers (PM), and their staffs, in making effective software assurance (SwA) and software supply chain risk management (SCRM) decisions, particularly when they are developing their program protection plan (PPP). A secondary purpose is to inform DoD policymakers who are developing software-related policies.

Blog Posts by Stan Wisseman
Launching a Software Security Program – What does it take?
Critical Application Resiliency – Building cybersecurity into apps from the start
Top 5 Ways to Improve your Security Program (application security is referenced)

OWASP AppSensor Project
The AppSensor project defines a conceptual framework and methodology that offers prescriptive guidance to implement intrusion detection and automated response into applications.

The project offers 1) a comprehensive guide and 2) a reference implementation. These resources can be used by architects, developers, security analyst and system administrators to plan, implement and monitor an AppSensor system.

ESAPI Swingset
The ESAPI Swingset is a web application which demonstrates the many uses of the Enterprise Security API (ESAPI).

Tysons Corner      Toronto     New York     Atlanta     Sunnyvale     Costa Mesa

Tysons Corner

Moving Beyond Penetration Testing for Repeatable Software Security Assurance
Security testing objective is to validate that security requirements/controls operate as intended and that the application is free of or has few vulnerabilities that could be exploited.

While black box penetration results can be impressive and useful in demonstrating how vulnerabilities are exposed in production environments, pen-tests are not the most effective or efficient way to secure an application. Results from a pen-test can help the case for more budget, confirm compliance (PCI), or validate that security controls operate. However, while you can fail a pen-test and know that you have a very bad problem. If you pass a pen-test you do not know that you don’t have a problem.  Pen-tests should only be considered as an implementation technique to raise awareness of Prod issues. It should be the last check to ensure nothing has been missed. It’s been proven that penetrate and patch isn’t a successful means of gaining assurance. We need to be testing early and often.

We generally agreed that integrating security into the SDLC is the target approach – need to think strategically, not just tactically. Some expressed challenges in securing budget or executive buy-in to move left in the lifecycle. Dealing with legacy apps and getting identified security defects mitigated is also a problem – no funds to resolve root cause. We discussed WAFs and RAST as a means of mitigating residual security defects in Prod applications. Applications need to have exception handling to cope with hostile environments and generally be more resilient.

There is a cultural and mind-set shift that needs to occur. Development teams need to have heightened awareness of secure coding practices as well as the threat landscape. Misuse and abuse cases need to be considered early in the lifecycle – not just the happy path. The security team should have gates to ensure that the dev teams get it right throughout each lifecycle phase.

John Keane shared his successes in establishing a successful software security assurance program. He uses a range of tools, including Fortify SCA.

If cars are built like most applications, safety test would include only frontal impact testing. Cars would not be roll tested, or tested for stability in emergency maneuvers, side impact, or resistance to theft.  We need to consider the software security assurance problem holistically. Pen-testing has a roll, but it’s not a silver bullet.

Measuring and Reporting ROI and Business Value from an SSA Program

• Culture determines SSA – risk appetite, etc. vary from organization to organization
• Consistent positive feedback from upper management around growing software security programs
• Focus on the business impact when positioning need to the business decision makers – not technical details/terminology/results – as well as the benefits (costs) of securing applications (along with the cost of NOT having secure apps)
• How to talk to The Board – again, not a technical discussion but talk to business implications of not having Security Retail all ROI data for the future – to support investment – or re-investment – decisions down the line.
• Make everyone know the value of an SSAG- Software Security Assurance Group.
• Some organizations the best way to get an SSAG going is “Name and Shame.”
  

Why Collaboration is Key to Software Security Assurance

• Get all your key stakeholders engaged as they tend to be disparate within many organizations
• Defensive is not the way! Educate and collaborate (with developers); they can interpret as “accusatory”
• Including penetration testing is key. With increased government regulations and requirements, it is critical that any internal requirements are actionable, defined and understandable
• Comparative Metrics (“App Team A”’s results vs. “App Team B”s results) – can be an effective way to share data
• Relatable Communications: Security Teams need to speak to developers in a way they will understand and relate to – show real life examples
• Empower your development team – do not just feed them information.  This will allow for the developer (and development team) to take action on their own.
  

Toronto

Moving Beyond Penetration Testing for Repeatable Software Security Assurance

• How do you compare to Mark Graff’s software security model?
• Do penetration testing at gates and before going to production
• In some cases security is involved early and in other cases security comes in at the end
• TRA – Risk Assessments
• Identify assets and associated with importance – where is it located?
• Who can accept the risk cost/business impact  -- tied to financial impact in the event of a breach and you can approve that cost
• Have secure code libraries so you do not keep re-inventing the wheel and making mistakes
• Manual code reviews – Concentrate on importance or parts of code
• Self  (Disadvantage in large applications)
• Peer
• Need balance of manual and automated reviews. Automated code reviews are better for large-scale applications.
• Secure coding standards built into coding standards
• Prioritization of risk determines effort
• Threat modeling need at start of design
• 50% of errors at design stage
• 50% of errors at build stage
• Balance of Preventive, Detective & Corrective Controls required in system design and also in software security program. Use systems like Fortify (HP Enterprise Security).
• Training is VERY important
• Developers should do testing to garner immediate feedback and as a way to learn how to code more securely
• BE ADAPTIVE -- Overall you need to be adaptive to threats

Measuring and Reporting ROI and Business Value from an SSA Program

• Organizations measure ROI differently.  Depends on company size and SSA Program maturation.
• Some financial services companies and banks may be further along due to regulations
• Some companies do not have SSA as driver or written requirement
• Measuring ROI is not tangible.  Some are measuring it on time to market and the vulnerabilities.  Others are looking at the costs of making changes to the software itself retrospectively
• It is still a different discussion with leadership to provide a real dollar value in bringing an SSA program into your company or not
• Some companies are not mature enough which affects budget for AppSec
• Quantifiable metrics can be stop-gap
• In terms of ROI for a 3rd party developer or outsourcer – measuring ROI requires a different approach and can be worked into a contract via a High, Medium, Low clause on finding vulnerabilities in software code.  Keeps it simpler and clearer if you need to apply a penalty.
• Important to educate your developers – look at their vulnerabilities in their work.  And then how they are implementing controls into the SDLC.  Not a dollar value per-se but overall looking at who on your team is providing a better security posture.

Why Collaboration is Key to Software Security Assurance

• The topic of “Confluence” that was presented by Mark Graff during his keynote aligns really well with collaboration and this topic
• Who do we need to collaborate with?? The Development Team! Help them get the education that they need.
• Have the functional and non-functional requirements up-front
• Incentivize developers
• Encourage advocates & evangelists
• Enterprise architecture should be a part of the governance process
• Ensure when a team selects a solution it is not adding more risk
• Another topic is project management. If security is not considered up front and budgeted for, it will not be done.  It is not built into expectations.
• Procurement – acquisitions, business partners, vendors and MSSPs are adding additional risk into the environment.  They are pulling information out of your environment and if not trained properly it can add risk overall
• Some times you need to the stick and cover management buy-in but it not always possible.  Use a team approach to find a medium ground to manage your risk
• DO NOT BE THE NO TEAM!  BE THE GO TO TEAM!
• If you have a team that is able to talk the dev talk and tech talk and explain remediation – this will give you an advantage

New York

Moving Beyond Penetration Testing for Repeatable Software Security Assurance

• Pen Testing for some organizations is an alternate solution to having a SSA Program if an SSA Program was not in place. However, it really dependent on the organization if it was an either/or or having both if the SSA Program was more mature.
• Threat modeling and design makes for a strong SDLC.
• Excited about a newer SSA technology recently mentioned by Gartner that allows the scanning of run-time applications as it goes on the app server itself and scans it real-time. To-date 50-60 types of attacks can be detected.
• A trend of analyzing third-party vendors for SSA is now on the rise
  Today, SSA is not always a cohesive process or an SDLC itself as to bypass the SSA overall, developers are throwing the application to one group or to the next. These practices circumvent an SSA process/program.
• A downside and success barrier is having an SSA expert come into the production process to late in the SDLC

Measuring and Reporting ROI and Business Value from an SSA Program

• It is 35x – 60x more expensive to correct unsecure code once in production
• Gather benchmark data to demonstrate in putting value together to create your SSA Program
• If you have to do SSA as a proof-of-concept, baseline and use your numbers. Look at other areas to compare the cost of reputational risk and ROI. For example, if you are spending a lot of money on an endpoint security program, look at their success metrics to demonstrate and baseline the potential value (ROI) of SSA in your organization
• Know your applications and audience. Let them know that there are new standards and controls – i.e. ISO27001, SEC Privacy Laws in APAC, etc
• All organizations need an SSA program that demonstrates its value and shows how it can mitigate risk
• Consensus is to take key or core applications with initial funding and show progress. If possible gather data on the effectiveness of your competitors’ SSA programs or show industry benchmarks
• It is not suggested to go out of the gate and commence a multi-year SSA Program. Take baby steps and do a pilot to keep your core information safe – this will show your milestones, successes/failures as well as show progress. It will allow you to build a foundation for your business case for a full SSA program
• Be familiar with your audience whether it is the board, stakeholders, end users, developers or lines of business leaders.

Why Collaboration is Key to Software Security Assurance

• How to incentivize developers to effectively participate in a SSA Program -- bonuses by writing secure code? Number of defects?
• Solicit feedback from developers – very proud group. Problems are taken seriously and personally. Encourage positive and constructive feedback that is two-way.
• Come up with solid and defined business processes – whether you are using water-fall or agile development methodologies you need to be consistent and true or you will have constant challenges. Whatever the methodology utilized think through it from beginning to end – throughout the lifecycle
• Go through a peer code review process with your junior developers
• Reuse security code libraries – not everyone has to rewrite the code!

Atlanta

Moving Beyond Penetration Testing for Repeatable Software Security Assurance

• While black box pen testing results can be impressive and useful in demonstrating how vulnerabilities are exposed in production environments, they are not the most effective or efficient way to secure an application
• If you fail a pen test you know that you have a very bad problem. And in contrast if you pass a pen test you may not know you have a problem. Pen testing is a sanity check done later in the SDLC.
• In general move left in the SDLC as many QA Specialists do not always have a security mindset.
• Enable the development team to find defects during development itself. If you can catch the error during the design and architecture stage, you can prevent a lot of expensive rework later.
• Pen testing should be only considered as an implementation technique or to raise awareness of production issues. Should be the last check to ensure nothing has been missed but not as a substitute for SSA.
• Car Safety Analogy – If you do only pen testing during your application development than you are essentially only testing the front impact collision on your entire car. You need to test the entire car to be fully effective.

Measuring and Reporting ROI and Business Value from an SSA Program

• It is first important to understand your budget and where you are in the budgeting cycle—so where are you starting? And where are you going?
• Then look at the metrics to measure what you are getting and then getting in return
• Upward and downward communications as well as education are very important
• Most see their information security budgets either equal to the previous year or increasing overall.
• People at all levels across an enterprise are paying attention to information security.
• So when you get the money – you have to know what you are going to do with it and prove the metrics of your investment as well as the impact of it
• Information security is transitioning to business risk – transition and utilize a risk scoring system to articulate the appetite for risk and then measure ROI. It will translate well to Lines of Business Leaders and Board of Directors.
• Incentive programs – money, gifts, etc. to find bugs in other people’s work.
• Be cognizant of types of development methodologies – Waterfall and Agile. Both are different and the detection of errors and security vulnerabilities are different as is the timing.
• Let’s not only think about today but plan for the future – web, mobile apps, wearables
• Decide importance and priority of correction – do you fix the critical issues first? Or go for the low-lying fruit of commonality (i.e. cross eyed scripting).

Why Collaboration is Key to Software Security Assurance

• Security cannot do it alone! Collaboration with the development community is essential!
• Partner with the CTO and team up with your development counterparts – it is a powerful partner to have on your team
• Partner with your lines of business and business leaders so that they understand risk.
• Bring all parties to the table to collaborate – no one can work independently on SSA and be effective
• The cost of detection and correction is higher – the later you catch it.
• Talent acquisition is very important – be a part of the hiring process. Participate in the developer’s interviews and ask if they are trained on secure coding techniques
• Know your environment and understand your obstacles – legacy apps, unknown app inventory, resource allocation
• Do peer code reviews
• Chicken little the sky is falling messaging does not work for a long-term partnership. Create solutions that create collaboration!

Sunnyvale

Moving Beyond Penetration Testing for Repeatable Software Security Assurance

• Automation – how much can be repeated
  - Helps establish boundaries
  - OWASP
  - Rules based and repeatable
• Process
  - Pen testing is the least amount of effort and most time it means that a sufficient job was not done overall
• Build threat modeling into inception plan
• Operational measures are needed for security patches
• Organizational that are structured filter out noise vs. real threats/vulnerabilities

Measuring and Reporting ROI and Business Value from an SSA Program

• Biggest problems that we face
• Still can get breached with having a SSA Program in place or not
• Use of statistics potentially can offer a good ROI set-up
• Use consecutive years of information to compare and contrast
• Consider measurement around performance and efficiency around processes
• How many apps can we get through this year vs. last year?
  - Did it take more time, resources or bring forth a better outcome?
• Merge security program into the application development organization not a separate matter (or department) overall
• Security is simply an attribute

Why Collaboration is Key to Software Security Assurance

• Collaboration is Key!
• Challenges in global companies include:
  - Time Zones
  - Language Barriers
  - Cultural Differences
  - Role Barriers and their objectives – Marketing Director vs. Security Architect. Both have different missions, goals and agendas.
• Collaboration is needed to improve processes
• Calendaring can be challenging – getting 6 to 8 people together can extend a process
• Do a peer code review to enable processes and minimize over collaboration

Costa Mesa

Moving Beyond Penetration Testing for Repeatable Software Security Assurance

• Most people have an incidence response program in place as we live a world full of APTs
• Important to review systems based on context and helps guide you
• Risk assessments are averaging 2-5 years
• Measure in hours for a breach detection
• Can not apply patches to production systems as they can not be taken down – too critical
• When security projects and implementations are done individually and not as a team than you have a maintenance nightmare.

Measuring and Reporting ROI and Business Value from an SSA Program

• Measuring ROI is hard as security is perceived as an expense
• Biz people, IT and insource developers and outsource developers as well as the InfoSec Team all need to speak the same language about their Security programs to be effective and build a culture of consensus
• Develop and define the measurements of the security program and its business value up-front.
• Defining ROI does not have to be cost avoidance
• Use “customer confidence” as an ROI measurements – what would happen to the customer – vendor relationship if the trust was broken
• Use a metric based approach with 3rd party vendors and build into the SDLC with defect responsibility.
• Security is often tied to a mindset like insurance – cost avoidance.
• What is the cost of doing business?
• Use industry benchmark data to chart your ROI

Why Collaboration is Key to Software Security Assurance

• Domains and Kingdoms can be an obstacle! Collaboration is Key!
• Take advantage of “circumstances” and “events” to garner funding for security programs and to raise awareness
• Keep in mind not all people in an organization have an understanding of security – take this as an opportunity to educate and collaborate.
• Explain how consequences can happen to stake holders.