How do we get a SOC 2?” Do those words strike fear and anxiety into your heart as an infosec professional? Do you have visions of being buried under a mountain of fancy risk management software, endless numbers of spreadsheets, and losing sleep for weeks implementing complex audit logging software? Well, take a deep breath and join this talk, in which we break down how to achieve SOC 2 Type II compliance without losing your mind. Your guide today has led many companies of various sizes- but mostly tiny startups- through several years of successful SOC 2 audits, and is here to break it all down. Bring your notebook as we explain why and how.
This talk will not focus on endless checkboxes, or push compliance at the expense of security. Instead, it will be a real world view of how to achieve compliance audit success without wasting your time, creating busy work, undoing your hard work securing your users’ data, and building a resilient architecture. We’ll explore how to automate, what to automate, how to build a control set that fits your organization, and how to come out the SOC 2 hero.
10. Trust Services
Criteria
SOC 2 audits are generally
performed using the five
Trust Services Criteria
Security
Availability
Processing Integrity
Confidentiality
Privacy
11. Security
Does the company have an information
security program?
Has it has implemented some common
security controls, such as user security
awareness, access control reviews, &
encryption of sensitive information?
12. Availability
Have business continuity and
disaster prep controls been put
in place? Do they operate?
Is there monitoring in place to
detect outages?
13. Confidentiality
● Is there a data classification policy
and attendant procedures? Are they
followed?
● Is sensitive information stored on
disks destroyed when the disks are
decommissioned?
15. Processing
Integrity
Have controls been put in place
to check the accuracy of
system inputs & outputs? Will
these controls ensure that any
errors introduced in processing
data will be corrected?
16. Privacy
Are there privacy commitments
to protect Personally
Identifiable Information (“PII”)
within a system? Has the
system implemented controls
to protect PII from accidental
disclosure?
17. Confidentiality
vs. Privacy
“Confidentiality is distinguished from privacy in that privacy applies only to
personal information, whereas confidentiality applies to various types of
sensitive information.
In addition, the privacy objective addresses requirements regarding
collection, use, retention, disclosure, and disposal of personal
information.
Confidential information may include personal information as well as other
information, such as trade secrets and intellectual property.”
19. Choose your own
adventure
Unlike with other control
frameworks, with a SOC 2
you have some flexibility to
word your controls to
match your processes and
structure, within certain
parameters.
20. “2017 Trust Services Criteria for Security,
Availability, Processing Integrity, Confidentiality,
and Privacy”
https://bit.ly/3Br9Amn
22. Two controls to implement this
principle
1. Widgets, Inc. has an organizational chart which
defines reporting lines.
2. External third parties and their reporting within the
organization are defined.
23. Policy language to authorize the
information security program
"[COMPANY] Security Organization receives its
mandate from [COMPANY] management. All Information
Security policies are reviewed and approved by
management"
"[COMPANY] will create, review, and update necessary
policies and procedures to maintain security risks
to [COMPANY] at a reasonable and appropriate level."
24. SOC 2s focus a lot on processes and
records, and so you’ll want to focus
processes to implement these controls,
and think about sort of records you’ll
need to ensure you’re generating and
retaining.
27. The Principle:
CC6.1 The entity implements logical
access security software, infrastructure,
and architectures over protected
information assets to protect them from
security events to meet the entity's
objectives.
28. Some of the relevant points
of focus
● Identifies and Manages the Inventory of Information Assets
● Restricts Logical Access
● Identifies and Authenticates Users
● Manages Points of Access
● Manages Credentials for Infrastructure and Software
29. Control to show Authentication
CC6.1 "Access to the AWS console is restricted to designated personnel, based
on documented policy. Access requires use of multi-factor authentication.
The following password parameters are enforced:
• must be at least sixteen characters long
• must contain at least one number
• must contain at least one upper case letter
• must contain at least one lower case letter"
30. Control to show Role Based Access & Least Privilege
CC6.1 AWS security groups are configured to only allow specific services to
specific destinations and all other services are not permitted.
32. The Principle:
CC8.1 The entity authorizes, designs,
develops or acquires, configures,
documents, tests, approves, and
implements changes to infrastructure,
data, software, and procedures to meet
its objectives.
33. Some of the relevant
points of focus
● Manages Changes Throughout the System Life Cycle
● Authorizes Changes
● Documents Changes
● Tests System Changes
● Approves System Changes
34. Controls to show Change Management Process
CC8.1 Code, configuration, and infrastructure changes are documented in the
source code and deployed through the continuous build system after passing
automated tests.
CC8.1 Changes to production infrastructure are deployed using infrastructure as
code and follow the documented SDLC process.
41. Remember these two controls for
CC1.3?
1. Widgets, Inc. has an organizational chart which
defines reporting lines.
2. External third parties and their reporting within the
organization are defined.
42. “Widgets, Inc. has an organizational chart which defines
reporting lines.”
Evidence we may be asked to provide:
1. A print out or screen captures from an HR tool like Gusto that shows the org
chart
2. Screenshots from a management tool showing the managers of selected
employees
43. “External third parties and their reporting within the
organization are defined.”
Evidence we may be asked to provide:
1. A screenshot from a HR tool showing that any contractors have a defined
supervisor.
2. PDFs of contracts with third parties showing the designated responsible party
within an organization.
44. What about these controls?
1. Changes to production infrastructure are deployed
using infrastructure as code and follow the SDLC
process.
2. AWS security groups are configured to only allow
specific services to specific destinations and all
other services are not permitted.
50. Your goal:
Create a timestamped record of an
event happening & who did it. The
“who” should be a person logged into a
system, captured within the system (like
a code reviewer logging a GitHub
review or a Jira commentator).
51. Good:
● Jira ticket
Decent:
● Entry in a Google Workspace Spreadsheet
OK:
● Email
Not So Great::
● Entry in a plain text file
53. What systems will be
audited?
As you prepare for your SOC 2 audit, you should think carefully about what your
audit scope will be.
● Just your cloud?
● All systems, including user laptops, that touch customer data?
● If you run multiple SAAS tools, which ones are you including?