Product Engineering teams have started to realize the importance of software security. This has resulted in the trend where teams are taking efforts to include it as part of their software development life cycle; as opposed to treating it as another item in their checklist prior to release. However, the real challenge is in trying to find the balance between agility and quality which is where many team find this an uphill task.
While there is no golden standard when it comes to implementing software security, product teams should focus on bringing about systematic and cultural practices within their teams. This should help them to bring about the required efficiency to enable software security as a market differentiator.
This slide-deck on Software Security Initiative focuses on translating a plan of action into sustainable activities as part of the secure software development life cycle that can be adopted by engineering teams. The slides will delve deep into aspects like identifying and designing security checkpoints in the SDLC alongside concepts such as Threat Modelling in Agile, AppSec Toolchain and Security Regressions.
This was presented as a we45 Webinar on April 12, 2018
4. Phases of an SSI
Prepare to Kick Start / Improve your SSI
Take Control and Implement your SSI
Measure Success of your SSI
Identify Continuous Improvements of your SSI
PLAN
DO
CHECK
ACT
5. In focus today…
Application Team Mapping
Gather Historic Current State Data
Ascertain Compliance Legal Objectives
Establish SSI Governance
Identify Training Needs
Organize Tool-chest
Identify Security Checkpoints
Toolchain implementation
Enhance existing automation
Build Internal Capability
SIG Collaborations
Transcend Beyond Penetration Tests
Enforce Security Checkpoints
PLAN
DO
6. The Advent of DevSecOps
Ø Security = Continuous Feedback + Improved Automation
Ø End of the chain security activities broken down into piece-meal engagements
Ø Division of security responsibilities – Dev, Ops, QA, Security
Ø Transformation of engineering tools and platform – interfacing capabilities
Ø Everyone needs to “get” code
9. Security Checkpoints
Ø Logical security turnstiles at every phase of development and deployment
Ø Assimilate common security objectives across engineering teams
Ø Establish traceability for identified security flaws
11. SOFTWARE DESIGN
“There are two ways of constructing a software design. One way
is to make it so simple that there are obviously no deficiencies.
And the other way is to make it so complicated that there are no
obvious deficiencies”
C.A.R Hoare
12. Threat Modeling
Ø Identify, Enumerate and Prioritize - Security Risks
Ø Systematic Breakdown of Attack Vectors and Attack Channels
Ø Identifying Most Likely, Relevant Threats to a system
Ø To identify controls and measures of risk treatment
Ø Create a Security Playbook for the Product Team
13. Everything that’s wrong with Threat Modeling today
Ø Assumption of frozen requirements => Very Waterfall!
Ø Threat Models are not dynamic enough - Out of date with application delivery
Ø Current Threat Modeling is not collaborative – Bunch of Security folks at the
beginning of a project
14. The 1-2-3 of Threat Modeling
Abuser
Stories
Attack
Model
Test
Scenario
User Story
What can be done to
abuse a functionality
How to make your
abuser story come to life
Security checks you can formulate
for each attack model
15. Threat Modeling :: Test Case Mapping
User Story
As a user I want
to search for
my notes using
the Search
functionality
Abuser Story
As an attacker, I
will try to search
for notes of other
users so as to
disclose
potentially
sensitive info
As an attacker I
will try to redirect
users to
malicious sites to
compromise
account
credentials
Attack Model
Attacker can
perform Man-In-
The-Middle
attacks
Attacker can
perform Injection
attacks
Test Scenarios
Check if the
application is always
on HTTPS, across
the application
Check for SSL
strength
Check for HSTS
header present in
HTTP Headers while
connecting to the
application
Check for SSL
vulnerabilities like
POODLE, BEAST…
16. Security in Design
Ø Consolidate security requirements
§ Compliance mandates
§ Regulatory obligations
Ø Perform architecture design review
Ø Perform Threat Modeling
Ø Third party threat feeds / historic data
Ø Identify relevant SAST, SCA & DAST tool-chest
Ø Prioritize training needs
Design Checkpoint
Abuser Stories linked
to User Stories in
JIRA/Confluence
17. DEVELOP & DEPLOY
“The most secure code in the world is code which is never
written”
- Colin Percival
18. Develop
Ø Table – Top code walkthroughs
Ø SAST IDE Plugins
Ø SCA runs as part of code review and build
management
Ø Peer-review prior to code commit
Ø Evangelize use of Secure Coding
Guidelines/checklist
Ø Liaise security champions
Develop Checkpoint
SAST and SCA scans
on local repo prior to
code commit
19. AppSec Toolchain
Ø Security tools (SAST, SCA and DAST) to work in conjunction with engineering platforms
Ø “Force Multiplier Effect” through open source scanner components
Ø Automated or scheduled triggers that kick off scan workflows
Ø Transform from plain DAST to Parameterized DAST
Ø Save critical security bandwidth by minimizing
§ Vulnerability Triaging
§ Testing common scenarios
§ Reconnaissance and Discovery
Ø Transform vulnerabilities as “defects” routing them to the common defect pipeline system
