This document summarizes a debrief presentation on appsec management given in London in December 2016. It notes that the organization's applications currently have high security risks that have not been fixed, there is no appsec team, and the security of the applications and ability to detect attacks cannot be assured. It proposes creating a "Legacy-SecDevOps" team to focus on fixing security issues, refactoring code, and improving testing and deployment over 6 months to help kickstart an appsec program for 2017. The team would work to improve security practices like threat modeling, reviews, and monitoring across the organization.

1. AppSec Management Debrief
Dinis Cruz, London, Dec 2016
Legacy-SecDevOps

2. Disclaimers
▸ This is a debrief for managers, business owners and C-Level
executives (CTO, CISO and CEO)
▸ The ideas presented are an independent assessment of the
current situation, based on an short and very high-level
code review and training session
▸ Some information provided can be controversial if taken out
of context
▸ There is strong agreement by the Development Team of the
ideas and actions proposed in this presentation

3. Increased risk of Cyber attacks
https://www.statista.com/statistics/267132/total-damage-caused-by-by-cyber-crime-in-the-us/
Amount of monetary damage caused by reported
cyber crime from 2001 to 2015 (in million U.S.
dollars)
http://www.safety4sea.com/cyber-security-at-sea-2/
http://www.safety4sea.com/cyber-security-at-sea-2/
http://www.forbes.com/sites/rogeraitken/2016/02/25/cybercrime-presents-biggest-disruptive-threat-to-finance-markets-looms-large

4. Executive Summary

5. Hedged bet
▸ The Board, CTO, CSO and business owners are betting their
careers on:
▸ the security of the existing applications, and
▸ its ability to successfully detect, contain and react to malicious attacks
and code
▸ Today there are still a large number of High Risk security risks
that have not being fixed
▸ users are at high risk of exploitation
▸ A number of High Risks have been recently discovered, and
▸ there is NO ASSURANCE that these where the only ones
▸ There is currently no excuse (in the marketplace) for the kind of
issues and vulnerabilities that currently exist in production:
▸ it is ok to have had them in past,
▸ but now (2016), since they are well understood
▸ NOT fixing them shows lack of duty-of-care for user’s Data and
shareholders

6. Website is NOT Secure
▸ There is no AppSec team
▸ There is no knowledge of how many security vulnerability
are already known (and successfully exploited) by existing
attackers
▸ lack of visibility in existing log infrastructure for application based
attacks
▸ Older parts of the codebase should NOT be seen as
‘legacy’ since they are is still responsible for a significant
percentage of web traffic and profits
▸ With the current state of affairs, the claim to have a secure,
robust, resilient and modern platform cannot be made (to
the marketplace, shareholders and users)

7. No formal risk acceptance workflow
▸ Risks are communicate in non official mediums
▸ Emails, face to face, meetings, wiki
▸ Real risk of decisions made is not known and understood
▸ Security decisions and focus are not based on data
▸ Solution:
▸ Business owners and CTO need to ‘Accept Risk’
▸ Use Jira or GitHub Risk Workflow

8. Legacy-SecDevOps
▸ Legacy code will still be live in the next 3 to 5 years
▸ Dangerous strategy
▸ The idea of:
▸ ‘replacing an complex system that is hard to change (and understand) …
▸ …with a new completely separate complex system built on new
technology’
▸ very rarely works
▸ Better model is ‘incremental changes, with compatible new features’
▸ Create ‘Legacy Development Plan’ with team to execute it
▸ Good name for this team would be: Legacy-SecDevOps
▸ This team will focus on:
▸ fixing security issues
▸ refactoring
▸ testing
▸ deployment
▸ No new features to be added in the first 6 months of work

9. If there is no desired to fix Legacy code
▸ At least:
▸ Prepare multiple ‘disaster recovery and incident response plans’ so that
when (not if) there is an incident
▸ Run regular fire-drills to test and fine tune these plans
▸ Buy Cyber-Hacking insurance
▸ which will be more expensive that what is being proposed here
▸ Officially accept (in JIRA Risk Workflow) these Risks:
▸ Application is not a secure platform
▸ Application has not been thoroughly reviewed for AppSec security risks
▸ The extent of how many AppSec issues exist is not known
▸ There are a number of open high risk AppSec risks with no plans to fix
them
▸ It is not possible to detect malicious attacker’s probing and exploitation
▸ It is not possible to selectively remove vulnerable features
▸ Security risk and exploits on Application will affect all applications co-
hosted on same domain

10. AppSec MIA

11. AppSec vs InfoSec
▸ InfoSec is about:
▸ Networks, Firewalls, Server security, Anti-virus, IDS, Logging,
NOC, Policies, end-user security, mobile devices, AD/Ldap
management, user provisioning, DevOps, ….
▸ AppSec is about:
▸ code, apps, CI, secure coding standards, threat models,
frameworks, code dependencies, QA, testing, fuzzing, dev
environments, DevOps, ….
▸ If your ‘InfoSec’ team/person cannot code (and would not
be hired by the Dev team), then that is NOT AppSec.
▸ Both are equally important, but InfoSec is much more
mature, has bigger budgets and is understood by the
business

12. AppSec is where the action is
▸ Move to Cloud improved the Network Security and InfoSec
▸ Existing security infrastructure and detection is focused on
Networks (vs Applications)
▸ Firewalls
▸ Intrusion Detection
▸ DoS (Denial of Service) protections
▸ This is important, but the assets are all available at the
Application Layer
▸ Most attacks these days happen at Application Layer
▸ New code is being written every day
▸ Better technology makes it better than ‘legacy’ code
▸ Improved security awareness makes it a bit better
▸ Root cause of past security issues is still there

13. No AppSec team
▸ There is NO AppSec (Application Security) team
▸ There are few internal resources with strong AppSec knowledge
▸ There is an InfoSec team which manages after the corporate
network, services and users
▸ For for developers (the ones writing code), there is no
dedicated team that is focused on Application Security
activities
▸ There is also NO network of Security Champions
▸ each team should have a dedicated resource (1 day a week) for
AppSec
▸ AppSec activities and very limited, sporadic and individual
dependent
▸ Good number of existing developers who are very interested
in participating (in AppSec team and as Security Champion)

14. AppSec
http://www.slideshare.net/AmazonWebServices/sec320-leveraging-the-power-of-aws-to-automate-security-compliance

15. Legacy-SecDevOps

16. SecDevOps
https://www.linkedin.com/pulse/devsecops-secdevops-difference-kumar-mba-msc-cissp-mbcs-citp

17. Key Concepts
▸ Execute this project for 6 months (Starting on 1st Jan 2017) and review
it afterwards (to measure its effectiveness)
▸ Use it to fund and kickstart the AppSec team in 2017
▸ Testing, dependency management and web services visualisation are
first class citizens
▸ Take one known Vulnerability and refactor all its code into a separate
module (aka micro-service)
▸ Use feature toggles to enable/disable on live systems
▸ Complete independent stack for development, testing and deployment
▸ use containers for development, QA and production
▸ Add Security activities:
▸ Threat Modeling
▸ Secure Code reviews and Secure Coding standards
▸ Automated Security QA tests (from unit-tests to integration-tests)
▸ with 100% code coverage
▸ Automatic Attack surface mapping and documentation
▸ Independently verified by 3rd party AppSec experts
▸ Live monitoring and visualisation
▸ Ability to respond to security incidents and attacks

18. Legacy-SecDevOps
▸ Automate CI and CD
▸ Fast deploys and rollbacks
▸ Monitor and visualise everything
▸ Run containers in production
▸ Multiple deploys per day
▸ Kanban workflow
▸ Low WIP count and Andon Cords
▸ Improve test coverage and quality of Test APIs/Technology
▸ Real-time unit test execution and Code Coverage in IDE
▸ SecDevOps Pipeline
▸ Detect sensitive code changes (trigger secure code review)
▸ Automatic deployment of air-gapped QA sites (with surrogate
dependencies for external components)
▸ Automatic execution of tools (Static and Dynamic)

19. Positive impact of investment
▸ The processes, best-practices, technology and knowledge
gained will propagate to other teams
▸ Use Security and Legacy-SecDevOps project as an strategic
opportunity to drive changes across the organisation and raise
the bar of development, testing and QA
▸ Great opportunity to learn how to embed Security practices,
process and technology in to the SDL (Software Development
Lifecycle) and CI (Continuous Integration) pipeline
▸ Team participants will bring back to their original teams
knowledge gained
▸ SOC (Security Operations Centre) will gain new tools and visibility

20. Legacy-SecDevOps budget
▸ Who pays for it:
▸ Operational budget (from legacy app’s profits)
▸ Research and Development budget
▸ Teams that contribute resources (for 6 months)
▸ AppSec Insurance budget
▸ Data breach or attack will cost more than fixing issues:
▸ Current data breach law in UK allows IC to fine up to £500k
(https://ico.org.uk/about-the-ico/what-we-do/taking-action-data-
protection/)
▸ new GDPR regulation (in uk by 2018) will allow fines up to 4% of
Global Turnover (see https://ico.org.uk/for-organisations/data-
protection-reform/overview-of-the-gdpr)
▸ View Legacy-SecDevOps project as an insurance policy

21. Team
▸ Create ‘task force’ team to tackle this project (Legacy-
SecDevOps) using internal resources (where possible)
▸ Senior Security Architect
▸ Senior AppSec engineer
▸ 3x Senior Dev/QA
▸ 3x Graduate Dev/QA
▸ 1x DevOps
▸ 1x Project Management
▸ 30x days of Pentest services (external)
▸ All will be trained as Security Champions with the expectation
that they will bring back the knowledge and workflows to
their original teams
▸ This is a template for ‘dev/transformation task force(s)’
which can be selectively used to drive strategic technological
changes

22. DevOps workflow
1. Developer commits change to Git or merges ‘feature branch’ into master
2. Build server, detects commit and:
i) Clones repo, checks out branch
ii) Builds app
iii) Run Unit Tests and Quality/SAST tools (Static Application Security Tests)
iv) Deploy app
v) Run Integration tests and Performance/DAST tools (Dynamic Application Security Tests)
3. Pre-live servers (and QA container’s host)
i) Deploy app to pre-live environment
ii) Run more Integration and security Tests
4. Live servers (and live container’s host)
i) Deploy app to an live container
ii) Run and schedule smoke tests (with updated tests from original commit)
iii) Deploy (in regular intervals) to multiple audiences
a) only developers and business owners
b) 1% low impact users, then 10%, 25%, 50% and 100% of low impact users
c) 1% high profile users, then 10%, 25%, 50% and 100% of high impact users
(this workflow applies for all ‘push to prod changes’, ideally the smaller the better)

23. Security Champions

24. JIRA Risk Workflow
▸ Capture risks and make them accountable
▸ See ‘SecDevOps Risk Workflow’ book for more details
https://leanpub.com/secdevops

25. Thanks