This document discusses a presentation about the journey of migrating applications to the cloud while securing them. It describes challenges with application security and how traditional security tools are not sufficient for modern development environments. It advocates for integrating security into the entire software development lifecycle using an approach called DevSecOps. Specific examples are provided about how SAP Concur integrated Contrast Security's application security platform into their processes and cloud migration to AWS to help shift security left.
How AI, OpenAI, and ChatGPT impact business and software.
SAP Concur’s Cloud Journey
1. • Rory McEntee, Director of App Sec, SAP Concur
• Scott Ward, Principal Solutions Architect, Amazon Web Services
• Jeff Williams, Co-Founder & CTO, Contrast Security
A Journey of Chutes & Ladders
Real World Ups and Downs of Migrating
to the Cloud & Securing Applications
8. Business Drivers
• Improve security posture
• Maximize developer time with meaningful findings
Technology drivers
• Ease of use is paramount
• SDLC workflow fit is important
• Ability to automate and scale
• Reduce the surprise factor
Economic Driver
• Total cost of ownership is important
Key Drivers
14. Automate
with deeply integrated
security services
Scale with superior
visibility and control
Largest network
of security partners and
solutions
Inherit
global security and
compliance
controls
Highest
standards for privacy
and data security
Move Fast & Stay Secure
15. Business Imperatives
Competing forces
Development
Build it faster
Operations
Keep it stable
Security
Make it secure
D E V O P S
BUILD TEST DISTRIBUTE
MONITOR
Developer
s
Users
D E V S E C O P
S
BUILD TEST DISTRIBUTE
MONITOR
Developer
s
Users
SECURITY
15
Why DevSecOps
16. 16
Pre Commit Commit Acceptance Deploy
Continuous Compliance
Threat modeling
Initial *AST inside IDE
Code review
“Break the build“
Compile/build checks
SCA
Container security
Additional *AST
Unit test
Secure infra build
Functional testing
SCA *AST
Unit testing
Security attacks
Detailed *AST
Fuzzing, Pen Tests
Provision runtime
environment
Config management
RASP
SECURITY
COMPLIANCE
CI/CD
DEVOPS
Security & Compliance of the Code in the
Pipeline
Security & Compliance of the Code in the Pipeline
17. Customers have their
choice of security
configurations IN
the Cloud
AWS is responsible
for the security OF
the Cloud
AWS Customers control their own security policy
Shared Responsibility Model
18. Cloud & Security Migration Journey High Points
ANDMove fast Stay secure
25. Steps to Success – Implementation Roadmap
Train
• Lunch and Learn
• Onsite Training
• KPIs and Reporting
• Vulnerability
Management
Workflow with CTE
• Current & Future
state workflow
mapping
Scale
• CI/CD integration
• Automatic ticket
creation
• Instrument Chorus
DT and TMC
services
• Leverage OSS
• Developer Training
Systematize
• CI/CD integration
• Vulnerability
Management for the
next apps
• Deliver Policy
Compliance
Reporting
• Developer Training
Replicate
• Onboard next in line
apps
• OSS
• Developer Training
Jun
May
Apr
Build
• TeamServer
Implementation
• Single Sign On
• CTE App on
Faraday cloud
instrumented
• Jira Integration
• Launch Internal
Collateral
Mar
Done
At first we started with just instrumenting our own instances of Faraday. We’d instrument the big app, do our usual pentest things, spider the pages we could crawl. We were able to uncover some very interesting and valuable findings that have previously gone undiscovered, even after years of beating up the big app for years.
The next step for us was to roll this out to everyone’s instance of Faraday. That was easy to do with Faraday’s post-provision process. Whenever you run `faraday post-provision` to set up your new cloud instance, a bunch of powershell scripts get fired off in the. Teams can add their own provisioner scripts to do just about anything: install more tools, tweak configs, run automation, you name it.
Working closely with the Faraday team, we did our own automation that allows instrumenting the big app with the Contrast .NET agent. This post provisioner simply downloads the .NET agent from artifactory, pulls some config files and sets things up, then runs the agent installer in headless mode. It’s as easy as that, and our post-provisioner is the part of the core set of post-provisioners very soon. Every team that uses Faraday is now a consumer of Contrast, and is contributing to our code security coverage by doing their normal day to day development and testing.
At first we started with just instrumenting our own instances of Faraday. We’d instrument the big app, do our usual pentest things, spider the pages we could crawl. We were able to uncover some very interesting and valuable findings that have previously gone undiscovered, even after years of beating up the big app for years.
The next step for us was to roll this out to everyone’s instance of Faraday. That was easy to do with Faraday’s post-provision process. Whenever you run `faraday post-provision` to set up your new cloud instance, a bunch of powershell scripts get fired off in the. Teams can add their own provisioner scripts to do just about anything: install more tools, tweak configs, run automation, you name it.
Working closely with the Faraday team, we did our own automation that allows instrumenting the big app with the Contrast .NET agent. This post provisioner simply downloads the .NET agent from artifactory, pulls some config files and sets things up, then runs the agent installer in headless mode. It’s as easy as that, and our post-provisioner is the part of the core set of post-provisioners very soon. Every team that uses Faraday is now a consumer of Contrast, and is contributing to our code security coverage by doing their normal day to day development and testing.
Look onboarding with Contrast is not very difficult. The thing for us is really about scale and automation. We had been using Contrast for a little while, onboarding sub-parts of our massive app steadily. Now we had to ramp it up and automate. Our goal here was
Just a bit of background - all of our .NET code hangs out on IIS.
The Contrast .NET agent is point and click, run the wizard
To automate the process, we just ran it in the headless mode
Contrast agent instruments all code running under that IIS instance, so any projects there are automatically instrumented
At this point we have fully automated implementation of Contrast agent which would take just a few seconds to install ,and the results start streaming in almost instantaneously
The next challenge was: How can we capture all teams’ projects, all integration testing, and really maximize code coverage? The answer for us is faraday. Which is internal project name for what we do with AWS services. <<Lightweight explanation for Faraday>>
<NEXT SLIDE>