devopsy.kinsta.cloud

Tag: SOC 2

  • Putting the Security Into DevSecOps

    Putting the Security Into DevSecOps

    The non-Newtonian fluid that’s composed of cornstarch and water has been around a long time, but Dr. Seuss’ 1949 book was the impetus for what it’s often called today – Oobleck, from “Bartholomew and the Oobleck.” When not under pressure, Oobleck is a thin liquid; when pressure is applied, its resistance increases to the point of being solid. A couple of other examples are quicksand and Silly Putty ™ (for fun, this video shows how resistant Oobleck is against Thor’s Hammer). Company application security is much like Oobleck. When not put under stress, security appears to be a fluid mess of policies, procedures, guidelines and a host of other controls that seem to have no real connection. But when there’s an event of interest, incident or even a breach, those policies and procedures (P&Ps) come together to make their worth known.

    DevOps—What’s in a Name?

    DevOps has been around for a while now, and its definition is akin to a Newtonian fluid: Not well-defined except within each company or organization. This lack of a standard definition has its merits, though; giving each company flexibility in determining what it means for them, and the benefit of maintaining the best of development, security and operations no matter what it is called. Attempts at bringing all aspects of these disciplines together, regardless of the nomenclature used, are both old and recent. It’s a reframe of Shakespeare’s line, “What’s in a name?”

    Security has to be part of the DevOps culture, whether it’s called DevSecOps, SecDevOps, SecOpsDev or just simply DevOps. Creators of software need to go beyond the desire to have a good process and move to understand that customers need the software to be secure in addition to being useful, delivered on time and with a good UX and that the business needs to develop and maintain a positive reputation and avoid breaches to the best of its ability.

    How does one put security into the DevOps process? One approach is to proceed as if the goal is to attain SOC 2. SOC 2 reports hold great value. While not universally recognized (SOC 2 is a US-focused security controls examination), they give useful details about the controls used. While SOC 2 is not on the level of ISO 27001, for international (to the USA, that is) prospects, it still divulges security control details that aren’t present in other standards.

    What if Attestations Are too Expensive?

    AppSec transparency is not only good for improving sales but for mitigating the problems caused by third-party breaches.

    For some vendors, especially newer or smaller ones, something like SOC 2 is on their radar but not yet feasible. Why? Cost–those and other attestations are often expensive. Is it worth it? Yes, but not if the financial expense will put the company at risk. Whether one has achieved SOC 2 or not, potential customers want to see transparency in a company’s security controls.

    In the process of going for SOC 2, there are two advantages: 

    • You’ll improve your security posture.
    • You’ll be ready for when those opportunities roll around.

    Let’s get started.

    Pieces of the AppSec Puzzle

    Actually, let’s back up a bit first. There are some policies that cover multiple areas of the company or product: Infosec policy, risk assessment, vendor management and acceptable use (AUP). These will require full company interaction and arrangement. I want to focus on what you can do, starting today, to improve your product security.

    Here are the policies to work on to put security into DevSecOps.

    • Software development life cycle (SDLC)
    • Incident response
    • Access control
    • Passwords
    • Change management
    • Logging and monitoring
    • System backup and recovery

    Each of these will require, for full effect, more people and departments than just you and your own. But these P&Ps can be directed internally toward your development and production teams; perhaps even IT and security.

    Here’s a list of each policy and its purpose:

    Software Development Life Cycle (SDLC)

    This is one of the first P&Ps to develop. You’re already doing this – just because it’s unwritten doesn’t mean you don’t do it. In the world of customer assurance, if it isn’t written, it doesn’t exist. Make it real and purposeful by codifying what you already do and improving as you go. This is a primary tool for AppSec (which includes web applications and APIs) and is almost solely within the purview of devs, engineers and QA. The product or service provided needs to have this foundational level of control to prevent common forms of attack.

    Incident Response

    This is also high on the list of P&Ps on the list. This is separate from the corporate IR plan; DevOps should have its own plan for dealing with technical emergencies, incidents and breaches. And this plan can be part of the overall company plan.

    Access Control

    Access control includes how users are authenticated and authorized, and includes least-privilege access, multifactor authentication (MFA) and service accounts. Prospects need to know that access to your production environment is well controlled.

    Company Passwords

    Company passwords as a whole are managed by IT and security, and often have a minimum of eight characters, require a certain number of special characters and other industry-standard requirements. But your software environment can go beyond that to enforce more stringent controls.

    Change Management

    Customers need to be aware that the software they bought is changed in an orderly and authorized manner, not through an ad hoc and ad lib process.

    Logging and Monitoring

    This is important for ensuring that activities such as access control and change management in your company have been performed properly, in addition to providing information for forensics in case there’s a breach.

    System Backup and Recovery

    Document and ensure your capabilities to restore data in a timely manner. Things happen; not just attacks—user errors, natural disasters, provider outages and the like.

    The process of each P&P looks something like this:

    It’s a straightforward and natural process, but the simplicity of the ingredients (like cornstarch and water) makes it very easy to overlook its effectiveness.

    Additionally, make these P&Ps available—whether in full or by using excerpts or summaries—to prospects and customers. A major part of driving security is opening oneself up to public scrutiny. This could be via a secure portal, a public-facing page or a ticket/request system.

    BONUS Assessment for Transparency

    Take a look at the Consensus Assessment Initiative Questionnaire (CAIQ) by Cloud Security Alliance (CSA). Level one, which is a free self-attestation, is an often-requested assessment. It’s fairly rigorous and may require you to level up security in your company, but it’s a well-respected and no-cost attestation and is available free for prospects and customers to view.

    The Next Step

    Inserting or improving security in the DevOps process is part of the true DevOps process. It’s a mindset and culture more than a title or official designation–and it’s possible.

  • DevSecOps: Bringing Compliance to DevOps

    DevSecOps: Bringing Compliance to DevOps

    In today’s fast-paced business environment, the division of DevOps and SecOps must be bridged to create DevSecOps

    Now that the “X-as-a-service” model has taken hold, enterprise infrastructure, integration and solution delivery has accelerated rapidly. Waterfall methodology has given way to the Agile framework of rapid, continuous development and delivery. This necessitates the use of automation to speed QA and change management.

    In the midst of all this change and activity, a deeper goal is to make security and compliance part of the dev process from the ground up. For this to succeed, teams must take on a DevOps mindset regarding these aspects—one that places a priority on fast delivery and automated workflows.

    The tricky part is that DevOps and SecOps/compliance thus far have had different priorities.

    DevOps focuses on things such as policy management, monitoring, code inspection and risk mitigation. SecOps needs to anticipate risk and ensure controls are retroactively mitigating compliance and security risk. The inherent conflict comes from a traditional view that security review should come after software development as a final check, but instead ends up becoming a fractious process of reconciling necessary controls into the release cycle.

    Because there is a natural tension between DevOps and SecOps, as they have different charters and cultures, bringing about the idea of shared responsibility can be difficult. DevOps can be seen as more of a do culture (Atlassian calls this a “do-ocracy”) and SecOps can be seen as a control culture and they are inherently in conflict. To fulfill the promise of teaming for shared responsibility, DevOps and SecOps should align on three key objectives: collaboration, communication and integration.

    The Benefits of Collaboration in DevOps

    Emphasizing collaboration between an organization’s operations, development, testing and support teams is what DevOps is all about. The focus is on reducing time to market and improving agility through rapid development and rollouts. However, before the process of development can begin, you need to start with a plan. At the planning stage of development is where security and compliance can start to be incorporated.

    Organizations need to build a system of record that can implement and orchestrate the SecOps portion of the development plan. Policies and controls can be widely disseminated across product and engineering teams to document the intention of controls, define their implementation and enable teams to collaborate with comments and feedback in one hub.

    Closing the DevOps Communication Gap

    There exists a communication gap between the security function and the rest of the dev organization, and it is critical that security practitioners bridge that gap. Compliance and security can be viewed pejoratively by other teams because people don’t understand them or see their relevance to users’ lives. But this, too, can be changed.

    For instance, it’s better to talk about a security risk in terms of project delays and unplanned, unscheduled work rather than talking about a breach or a vulnerability. When speaking to operations teams, it’s better to talk about availability and user privacy requirements as correlated with mean response time or system uptime rather than a data breach. To succeed in a world that’s moving at the speed of DevOps, security groups need to be able to articulate control requirements in both the language and tools that DevOps lives in, such as Jira and GitHub.

    Integrating Sec Into Dev

    For security practitioners, the most radical process departure here is often the high degree of automation and workflow tools in DevOps. The critical success factor for integrating security and development operations is to make control implementation easy and clear for developers to follow. For example, if the team is working toward a SOC2 security certification, then a clear control framework broken down into tasks and issues will ensure a smooth integration of security into the dev cycle. A SOC 2 attestation will also require evidentiary verification that controls are implemented throughout the software development life cycle (SDLC), including release cadence. The final critical piece to achieving readiness for a security certification is to have integrated risk assessment, controls gap analysis and audit-ready evidence for your observation period in one central place.

    DevSecOps: Greater Unity, Stronger Security

    In a world where everything is offered “as a service,” the pressure is on to iterate quickly and non-stop. To make this possible, the DevOps methodology relies on the speed that comes through automation. But security is sometimes overlooked in favor of speed. That means security needs to automate, as well, to keep pace with continuous delivery. The division of DevOps and SecOps must be bridged to create DevSecOps.

    Understanding the benefits of this collaboration will go a long way toward easing the transition, as will learning how to communicate those benefits in a language that appeals to all stakeholders. What will enable the collaboration is an orchestration and demystification of security and compliance for the entire dev team. When DevSecOps is straightforward and simple for developers to integrate security, there won’t be a reason not to, and your product and organization will be more secure.

  • Positioning Compliance as a Differentiator

    Positioning Compliance as a Differentiator

    As the threat landscape has become more perilous and complex, regulators have imposed a wide array of mandates designed to protect sensitive personal information. For most organizations, compliance is seen as the cost of doing business. However, if executed strategically it can not only improve a company’s overall security posture but shortens sales cycles and open the business to new markets.

    In order to turn compliance from a check-the-box line item into a valued business initiative, businesses need to identify all global, local and industry regulations that apply to their business and, also, strategically implement the processes and technologies that keep them compliant. Whether you’re targeting specific industry verticals or going after international customers, entering new markets requires continuous education about the latest in compliance and regulatory standards as they relate to data privacy and security.

    A good way to get started is to put together a roadmap for how you will get, and stay, compliant with the regulations relevant to your business. What follows is an outline of such roadmap.

    Start with the Basics

    When you’re building a house, a foundation is the key to a safe structure. This holds true for building a compliance roadmap for an IT infrastructure.

    The first step is to ensure the infrastructure is configured in accordance with Center for Internet Security (CIS) benchmarks. If operating in Amazon Web Services (AWS), ensure all AWS best practices are met. Setting this foundation will help meet basic security and compliance requirements and will simplify the compliance journey from the very start.

    Once the foundation has been set, it’s then time for the compliance, IT and security teams to determine which regulations apply to their business. This is the backbone of the compliance roadmap. The good news is that many of these regulations overlap so businesses can complete requirements for multiple regulations at the same time.

    First Stop: SOC 2

    As a component of the American Institute of CPAs Service Organization Control reporting platform, SOC 2’s goal is to ensure that internal IT systems are configured for maximum security, emphasizing the privacy of customer data. It’s specifically designed for service providers storing customer data in the cloud, and this means it’s becoming increasingly relevant as companies continue their cloud migrations. SOC 2 goes beyond a simple technical audit though, requiring businesses to establish and follow stringent security policies and procedures that encompass the security, availability, processing integrity and confidentiality of any data stored in the cloud.

    In order to achieve SOC 2 compliance, the organization first will need to establish an understanding of what normal looks like in their environment. It’s critical to baseline typical activity in order to be able to monitor for anomalies. This enables detailed audit trails that allow for deep, contextual insight into root cause, allowing organizations to remediate issues and thus keep up with SOC 2 requirements.

    The Roadmap Focal Point: GDPR

    The General Data Protection Regulation (GDPR) brought compliance into the mainstream. When GDPR passed, it established strict regulations for how organizations with European customers must handle customer data. The regulation is so broad, stringent and complicated that it has motivated many tech companies to create new job titles to ensure compliance.

    However, while there have been strict compliance regulations before, it’s the high financial stakes attached to GDPR that set it apart. A business can be fined up to 4% of its global revenue if it’s found to be non-compliant. Very few organizations can afford to take that kind of hit which is why so many make it the centerpiece to their compliance strategy.

    The privacy implications of GDPR are extensive but one of the most important and challenging requirements is the data breach notification. Organizations must notify authorities or specific data subjects within 72 hours of a breach. Most organizations are unable to locate sensitive consumer information within their environment, making this requirement near impossible. However, if the organization bakes data controls into its systems and enacts continuous monitoring and real-time intrusion detection, it not only becomes achievable but improves internal processes. 

    Go Broad with Certification Add-Ons

    Once you’ve done the basics, like SOC 2 and GDPR, organizations can then begin looking for compliance regulations that they can actually use as business differentiators. ISO/IEC 27001, for example, is a standard that SaaS organizations often use to demonstrate an aptitude for managing information security risks. The regulation formally specifies an Information Security Management System, a suite of activities concerning the management of information risks and lays out an overarching management framework to identify, analyze and address risks. Certification requires a host of documentation, including a clear information security policy, a risk assessment process and evidence of information security monitoring and measurement. The standard spans industry type, organization size and market, so it applies to just about any company.

    Compliance can be a powerful differentiator and business driver that inspires trust and confidence amongst prospects, customers and external partners. Although the above standards and regulations require extensive resources, non-compliance can result in fines and other punishment that can cripple a company. It’s important to remember that these compliance standards and regulations may have to be revisited, but once put into place and assigned to a dedicated compliance team, the once daunting task pays for itself.

    — Lindsey Hardy

  • CircleCI Achieves SOC 2 Compliance for DevOps Platform

    CircleCI Achieves SOC 2 Compliance for DevOps Platform

    CircleCI has achieved a SOC 2 compliance rating for the DevOps platform it makes available via a software-as-a-service (SaaS) model.

    Tad Whitaker, security manager at CircleCI, said CircleCI is the first provider of a SaaS platform for DevOps that has invested the hundreds of thousands of dollars required to achieve SOC 2 compliance.

    SOC 2 compliance requires organizations to pass an annual audit based on the Trust Services principles and criteria defined by the American Institute of Certified Public Accountants (AICPA). That criteria evaluate IT environments on everything from the cybersecurity controls they have in place to the integrity of the data management processes employed. A SOC 2-level certification means DevOps teams can have confidence in the fact that their data is being kept completely confidential, said Whitaker.

    With interest in best DevSecOps processes on the rise, Whitaker noted more organizations are starting to ask questions about how data is managed and secured on the cloud services they rely on to build and deploy applications. Cybersecurity professionals who are now participating in those processes are starting to ask challenging questions. To address those concerns, Whitaker said CircleCI created a team within the company to first attain SOC 2 compliance and, now, maintain it.

    That may lead to additional processes and controls being put in place, but DevOps teams can be confident that everything possible is being done to secure their data from prying eyes, including employees of CircleCI.

    A lot of the data being employed to build new applications is among the most sensitive an organization is likely to possess. As organizations embrace DevOps practices to drive digital business transformation initiatives, there’s a much greater need to ensure the DevOps environment is secure end to end. However, most of the DevOps platforms delivered as a service today are not able to validate the level of security they claim to have put in place, said Whitaker.

    It’s unclear how many organizations are going to insist of SOC 2-level certifications before agreeing to develop applications on a specific DevOps platform. However, SOC 2-level certifications are routinely required for cloud service providers so it’s only a matter of time before the same audit requirements are applied to other cloud services. The challenge will come when DevOps teams have to adjust their existing DevOps processes to accommodate the security processes that SOC 2-compliant cloud service providers are required to make.

    In the meantime, the days when DevOps teams could employ cloud services to bypass cybersecurity policies are coming to an end. Cybersecurity teams are finally catching up in terms of figuring out how to enforce cybersecurity policies beyond an on-premises IT environment. Not every DevOps team may appreciate the impact those policies may have on productivity. However, if the alternative is to have sensitive data that DevOps teams are now being held accountable for exposed on the web because of careless processes than the time to come to terms with cybersecurity has finally come.

    — Mike Vizard