AppSec Management Debrief

Dinis Cruz, London, Dec 2016

Legacy-SecDevOps

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

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

Executive Summary

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

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)

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

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

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

AppSec MIA

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

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

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)

AppSec

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

Legacy-SecDevOps

SecDevOps

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

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

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)

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

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

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

DevOps workflow1. 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)

Security Champions

JIRA Risk Workflow

▸ Capture risks and make them accountable

▸ See ‘SecDevOps Risk Workflow’ book for more detailshttps://leanpub.com/secdevops

Thanks