Automate Compliance by Design

Scott Schwan, Chief Product Officer, A-LIGN

1
1
 PLATFORM INFORMATION & QUICK TIPS

• Download the presentation deck from the MATERIALS window.

• Platform Windows can be hidden or expanded to fit your preference.

• Submit questions in the Q&A window.

• Use the HELP icon at the bottom for FAQ’s and system requirements.

• Experiencing technical difficulties? Try REFRESHING your browser!

2
 CPE CREDIT PROCESS
LIVE EVENT & ON DEMAND RECORDING

• You must view the live or recorded webinar for the required amount of time
(50-minutes). Check the CPE Credit window to view the timer.

• Your CPE Certificate will automatically appear in the ISACA CPE RECORDS
tab on the MyISACA page after completing the required viewing time.

• Please be patient. This process could take up to 48 hours for your CPE Certificate
and the CPE credit to be applied to your account.

• As a reminder, ALL ISACA webinars, the CPE credits and CPE certificates expire
365 DAYS POST LIVE EVENT. Please make sure you save the appropriate
documents to your personal records.

3
 TODAY’S SPEAKER

Scott Schwan is A-LIGN’s Chief Product Officer, responsible for the

product vision, strategy, and evangelism for the A-SCEND suite of
software and portal products. By acting as a conduit between
customers and building company-wide product alignment across A-
LIGN teams, Schwan and his team build products and user
experiences that customers love.

Prior to joining A-LIGN, Schwan was founder and CEO at Shujinko, a

SaaS startup focused on automating enterprise compliance. He has
worked in the field of Security and Compliance for 16 years, starting as
an auditor for PwC, a lead security engineer and director of Cloud
engineering for Starbucks, and the head of infrastructure and
Scott Schwan security for CardFree.

4
 OVERVIEW

DevOps Compliance by Case Study Call to Questions

Design action

5
 Ethnographic Research

• Sociologists use the term participant observation or ethnographic research

• It’s when a sociologist becomes a part of the group they are studying in order to
collect data and understand a social phenomenon or problem

• Huge opportunity for us as security and audit professionals to do the same with
the DevOps culture shift

6
 DevOps is About Culture

• Development

• Operations

• Finger pointing between development & operations

• Same finger pointing can occur between DevOps and Security & Compliance
today

• We can all learn from this culture

7
 The DevOps Ethos

Ethos: the characteristic spirit of a culture, era, or community as manifested in its

beliefs and aspirations.

The DevOps Ethos

Empathy Accountability Ownership

8
 DevOps – Speak the Language

● Learn to speak the DevOps

language

● Use their terminology to find

common ground and align on
goals

● Change the way we work

● Become an enabler rather than

a blocker

9
 Compliance Maturity Model

Optimized Initial
► No dedicated compliance team
► Company culture supports continuous compliance ► No formal processes in place
► Comprehensive processes are risk based and quantified ► No controls exist
► Controls widely implemented, automated, continuous

Managed Repeatable

► Compliance team w/ defined roles and responsibilities ► Dedicated compliance team member(s)
► Formal verification and measurement processes ► Basic governance and risk management processes
► Controls monitored and measured, w/ limited automation ► Limited number of controls in place and documented

10
 POLLING QUESTION #1

How often do you collaborate DevOps teams?

• Daily
• Weekly
• Monthly
• Annually
• Never

11
 Compliance by Design - OVERVIEW

Define Build Assess Automate

12
 Compliance by Design

Automate Define
Automate repeatable processes Know your requirements

Assess Build

Validate the requirements are in place Build to those requirements

13
 Compliance by Design - Define

● Know your requirements

● The definition of done or consistent acceptance criteria

● Include security and compliance requirements in this phase

● Help engineers to understand the building codes

14
 Compliance by Design - Build

● Software is engineered to specifications, tested, promoted

● Engineers need to understand the building codes; this includes security
and compliance building codes
● CI/CD pipelines include unit tests, quality of code tests, user acceptance
● Security specifications need to be prescriptive if we want it to be built to
spec
● Security and compliance tests, code analysis, and acceptance can be a
part of this system
● Caveat - we can’t slow them down!
15
 Compliance by Design - Assess

● During software development, bugs are inevitable

● Definition of done includes acceptable bug thresholds
● Treat security vulnerabilities and compliance findings like bugs
● These findings need to captured in the same place if we want to see them
addressed
● Continuous assessment and feedback in the development pipeline is key
to being successful
● Send reports to Slack/Discord/Jira, integrate with the systems developers
use and translate it into their terminology

16
 Compliance by Design - Automate

● DevOps teams love to automate repetitive tasks

● QA teams automate testing of functionality before code is
promoted
● The same goes for security and compliance automation
● Automation of the remediation activity helps to reduce the
number of security bottlenecks
● Automation for evidence collection helps to prevent
engineers from hating us
17
 POLLING QUESTION #2

My organization’s adoption of compliance automation increased during

the pandemic?
• True
• False
• I don’t know

18
 Case Study – Cloud Engineering

• Hired a team of DevOps professionals

• Defined the way we work to include security-based missions and values
• You build it, you run it, you secure it
• No more throwing security and compliance over the wall to the
security and audit teams
• Implemented security tooling in our platform to report back to the
security and compliance teams in an open book policy
• Embraced the DevSecOps ethos and evangelized throughout the
organization

19
 Case Study - Define

● Aligned on PCI-DSS 3.2 as our

base compliance requirement
○ Security team also
authored their own security
standard, however PCI
covered all of the same
controls

● Definition of done for the

DevSecOps team included
security and compliance
requirements

20
 Case Study - Build

● Deployments are required to be

automated

● Security checks occur early and often

with near real-time feedback to devs

● Transparent security controls assist the

developer in making the right choice

21
 Case Study - Assess

● During construction of our cloud

environment, leveraged software for
continuous assessment and
immediate feedback
● Reports and alerts were sent to Slack
● Security vulnerabilities and audit
findings “bugs” were tracked in Jira
● Same place software bugs were
tracked

22
 Case Study - Automate

● Repetitive tasks were automated

● Permissions requests
● Key Management
● Secrets Management
● Evidence Collection
● Sprints included identifying
opportunities to automate security
remediation and compliance

23
 POLLING QUESTION #3

The percentage of controls within my control framework that leverage

some form of testing automation?
• 100%
• 75%
• 50%
• 25%
• 0%

24
 Adopt and Evangelize

• Adopt some aspects of the DevOps ethos

• Empathy, accountability, and ownership
• Go to sprint planning
• Go to requirements specification meetings
• Participate or observe bug bashing
• Etc.
• Speak the language and relate it back to security and compliance
• You build it, you run it, you secure it
• Don’t throw security and compliance over the wall to the security team

25
 Q&A

26
THANK YOU FOR ATTENDING