devopsy.kinsta.cloud

Category: DevSecOps

  • Rust Momentum Intensifies | Elon Says No WFH

    Rust Momentum Intensifies | Elon Says No WFH

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: People won’t shut up about Rustlang, and Musk mandates Twitter teams return to the office. (more…)

  • Developer’s Guide to Fuzz Testing

    Developer’s Guide to Fuzz Testing

    Fuzz testing continues to grow in popularity among developers within the open source community. Google’s open source security (OSS) team recently reported finding more than 40,000 bugs in 650 open source projects through the use of fuzz testing. But if you have no clue what fuzz testing is (yet), don’t worry. You’ve come to the right place.

    What is Fuzz Testing?

    Fuzz testing is a dynamic testing method for finding bugs and security issues in software. During a fuzz test, a program or a function under test gets executed with invalid, unexpected or random inputs to uncover unlikely or unexpected edge cases. 

    Value of Fuzzing for DevSecOps 

    As we know, DevSecOps extends the approaches of DevOps and Agile by adding suitable security testing methods alongside every phase of the software development life cycle (SDLC), creating a dynamic and continuous testing process. 

    Part of that testing process can and should involve fuzzing to detect security and stability issues at all phases of the SDLC and empower developers to ship software quickly and securely. For example, to prevent regressions from going live by running automated fuzz tests on every code change.

    Especially in the automotive industry and complex embedded projects, where a lot of untrusted and complicated data gets processed, fuzzing brings excellent benefits to DevSecOps. Indeed, developers can apply fuzzing similar to unit testing to automatically test their security-critical modules for potential vulnerabilities. But with fuzzing on an integration level, they can also cover all the complicated and dangerous edge cases that can occur in the interaction between different modules. 

    Fuzz Testing Benefits

    Fuzzing code generates thousands of automated test cases in a second, with the fuzzer receiving in-depth feedback on code coverage and the program states reached to simulate the interaction of different modules during the execution of the source code. The fuzzer can adapt and mute its inputs based on runtime feedback in the following iterations to maximize code coverage. Some of the benefits are:

    1. (Almost) no false positives: If you find a crash, fuzzing provides you with the error source and the malicious input that caused the issue. So, you can be sure that each finding is a real vulnerability.
    2. Debug reproducible findings: Modern fuzz testing tools will provide you with the input causing the issue, including the source of the error. With this, you already have a lot of helpful information to reproduce the bug and load it directly into the debugger. 
    3. Find issues in forgotten edge cases: Because fuzzing is executing a program with invalid or random input, it also uncovers unlikely and unexpected edge case errors that would not otherwise have been revealed.

    Who Uses Fuzz Testing?

    As cybersecurity regulations and standards continue to expand globally, more and more organizations are extending cybersecurity programs and running automated security testing before they ship software. Whole industries, especially those that involve advanced quality and security regulations, are setting standards for security testing that recommend fuzz testing, including automotive, aviation, finance, healthcare, telco and energy.

    Digging deeper into the automotive industry, for example, a variety of International Organization for Standardization (ISO) and other organizational standards now recommend fuzzing:

    Best Practices

    The most effective way to do security testing, fuzzing included, is to do so continuously. This means integrating fuzzing right into your CI/CD pipeline. Doing so creates quick feedback cycles so developers can fix security vulnerabilities before the code is shipped. Integrating fuzzing tools into code hosting systems like GitHub is also valuable. Doing so allows communication and alerts to be shared across your DevOps team as soon as a problem is uncovered, which helps to facilitate fixing vulnerabilities. 

    What Bugs Can I Find?

    While the practice remains relatively new, fuzzing has already discovered thousands of bugs across different use cases. Bug and vulnerability types discovered include:

    • Remote code executions
    • Injections, which can be triggered by untrusted inputs 
    • Memory leaks: Incorrect memory allocation 
    • Exposure of sensitive data: Accidental exposure of personal data
    • Functional bugs: Inputs that are not being responded to 

    and many more bugs, such as undefined behavior, uncaught exceptions and buffer overflow. Learn more.

    Getting Started

    You can try out an open source fuzzer, like Jazzer (for Java testing) or the CI Fuzz CLI (for C/C++ testing). When you’re comfortable with fuzzing and want to use this approach in more complex environments, enterprise solutions offer added features like API fuzzing, reporting and CI/CD integration. 

    So give it a shot and join the community of open source developers using fuzzing to quickly and securely ship their software. 

  • How DevOps Helps With Secure Deployments

    How DevOps Helps With Secure Deployments

    DevOps is an approach to software development that emphasizes communication and collaboration between teams. It’s best known for bringing together people who previously worked in separate areas like engineering or testing; this allows them all to learn from each other as they work on projects together.

    DevSecOps helps organizations monitor and discover security risks throughout the development process rather than spending a lot on post-launch protective measures. This way, they are able to secure their product without overburdening developers with heavy-duty responsibility for what might turn out as an easy fix given time or knowledge differentials between team members—after all, they are responsible for building these things!

    The Goal of DevSecOps

    The goal of DevSecOps is to provide security best practices in a way that doesn’t disrupt team productivity.

    Secure development is the key to a smooth deployment process. It’s frustrating when you have security in your product but don’t see it being implemented or taken seriously. DevSecOps brings back that focus by reminding everyone just how important and necessary good hygiene practices are for both developers and operations.

    For security to be more effective and reliable, it should be incorporated from the very beginning. This means that instead of waiting until there is an issue or crisis before implementing measures for protection such as firewalls, encryption keys, etc.; you want your developers working on it up front so they can ensure everything will work well together later.

    It helps ensure security issues are found as early in the process as possible so it is close to decision-makers. It’s much easier (and less painful) when security issues can be fixed while you still remember what happened with your project—it’s like having an extra set of eyes on the project.

    Advantages of DevSecOps

    Security should be a high priority for any company looking to stay afloat in this digital age. From reducing risk to mitigating legal liability, identifying bugs earlier on during the project life cycle makes security management easier when things go wrong. Security becomes less painful as well since stakeholders will understand better why delays happen instead of just because “the team found issues.”

    If you shift your focus to include this earlier in the process, then costly issues can be discovered much faster and closer to where they happen, which will allow for more timely responses from developers or infrastructure engineers who must address those problems before moving on to another task.

    The goal of this system is to give Dev and Ops faster feedback on the work they are producing so they are notified right away.

    Achieving DevSevOps

    There’s no one right answer when it comes to implementing DevSecOps, as the needs of each organization will be unique. However, there are some common practices that can help to get you started.  

    Get Management Buy-In

    To make a fundamental shift in how your organization thinks about, builds and deploys software, you will need more than just peer-to-peer agreement. Management buy-in is necessary for this revolutionary change of mindset.

    The DevSecOps process is one that can help combat software vulnerabilities being exploited in production. It’s important for those who make decisions on risks versus revenue to see how this will benefit the company, or else it’ll be fruitless.

    Security is something that we should all be responsible for. It’s not just a concept or idea, but rather something tangible and real—something which can affect your company greatly if handled incorrectly by someone who doesn’t know what they’re doing. That’s why it always pays off in the end when employees take their own security concerns seriously; this will result in better decisions being made about how best to protect your assets from outside threats.

    You can’t just implement a new policy without management backing it up.

    Developer Responsibility

    DevSecOps takes security seriously by making it a part of the development process, not an afterthought. The entire team can work together to write more secure code and configurations that are robust against threats while also being easily reversible if something goes wrong—because they’re writing this stuff right from their own desks!

    It’s not just a job for security professionals anymore, either. It needs everyone from the CEO to contract workers to take responsibility for securing their own work instead of outsourcing the responsibility and expecting others to do it retroactively every time there is an attack or threat.

    Security and DevSecOps training

    There’s no quick fix for organizational culture, but it can be done. People are always resistant to change. There will initially be frustration as traditional behaviors are questioned and you create new ways of working that might not fit everyone right away.

    Managers who have a good understanding of these concepts will be able to alleviate some problems, and so will experienced engineers and other staff. It’s important for everyone involved in the process (from top executives down) to buy into this idea because it can’t succeed without their support.

    When everyone understands the DevSecOps approach, they’ll not only understand why it’s important but also see how to properly implement this new way of doing things.

    Implementing the Proper Tools and Processes

    While it is often easier said than done, getting buy-in and detecting security issues early in the pipeline sounds great. But achieving DevSecOps integration does not happen overnight, so you should start by looking at what you can do today to move this process forward more quickly.

    But there isn’t just one right way of achieving DevSecOps—every organization has its own unique methods for building software that needs to be considered when implementing these concepts across different organizations with varying cultures and workplaces.

    Key Points

    By introducing a new security component to the pipeline, DevSecOps is expanding our fundamental development and operations components with the DevOps best practices. DevSecOps is the future of software development. It ensures that security risks are monitored throughout all stages, not just after launch time when it’s too late to fix vulnerabilities and bugs before someone else exploits them for their own gain!

  • 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.

  • What SASE Means for DevOps Teams

    What SASE Means for DevOps Teams

    You have probably heard the acronym secure access service edge (SASE), and it’s hard to ignore its impact on the technology industry. SASE is a cool new way to implement networking in hybrid environments, and the most important thing about it is that it bakes security into the network fabric. In plain English—when you plug in, you are secure by default. 

    SASE will have a special impact on two fields near and dear to the hearts of DevOps teams:

    1. Cloud security—SASE has the potential to transform how we practice security in the multi-cloud, and unify it with security in the central data center.
    2. DevSecOps adoption—SASE can make DevSecOps easier to adopt and might become essential infrastructure for globally distributed DevSecOps teams.

    Let’s understand the anatomy of the SASE beast, and understand how it will affect DevOps in the years to come.

    What Is SASE?

    SASE is a cloud service that extends networking and security capabilities to support hybrid organizations’ dynamic, secure access needs. 

    SASE combines WAN capabilities with network and security functions, such as firewall-as-a-service (FWaaS), zero-trust network access (ZTNA), secure web gateway (SWG) and more.

    A SASE platform bundles multiple security capabilities, including SD-WAN and services like SWG, CASB, ZTNA, FaaS and SaaS. This multi-region, multitenant architecture supports a distributed and remote workforce. SASE uses inspection engines located at points of presence (PoPs) near the endpoints rather than in the data center. SASE clients send traffic to the nearest PoP. 

    The core characteristics of a SASE architecture are:

    • Global SD-WAN—A private SD-WAN backbone helps reduce latency by avoiding the public internet. 
    • Distributed architecture—SASE inspects traffic and enforces policies at the edge using multiple inspection engines. 
    • Cloud infrastructure—SASE delivers services via the cloud, so tenants don’t have to maintain hardware and other infrastructure resources. This approach is scalable and cost-effective.
    • Identity-based access—Access controls use identity markers like the user’s location and device. 

    SASE Adoption Drivers: Why Do Organizations Want It?

    Cost Reduction

    Using physical and virtual appliances from multiple vendors is highly cumbersome and costly. SASE enables organizations to replace this disparate model with a single, cloud-native solution. Organizations can use SASE to deliver more technologies and services via one provider instead of several. As a result, it eliminates the cost of miscellaneous network appliances and optimizes cloud costs, by reducing the resources and bandwidth needed to operate a cloud environment. 

    Edge-to-Edge Security

    SD-WAN is an integral component of SASE, providing features such as an active-active failover and WAN optimization that improve performance and increase network resilience. SASE solutions are based on the concept of security automation, with a fully managed network security stack that typically includes SWGs, next-generation firewalls (NGFW), next-generation network architecture and intrusion prevention systems (IPS). This model helps protect all edges, achieving better network visibility.

    Data Protection

    SASE provides a holistic data protection experience that automates multiple DLP processes, including data discovery and data classification of storage locations, data usage and data in transit. It employs various security measures, such as user and device authentication, to enable control over access to data and resources at all times. Additionally, SASE DLP seamlessly rolls out protection policies across the entire network.

    Impact: How SASE Will Transform the Cloud Security Stack

    The emergence of services like PaaS, SaaS and IaaS has encouraged organizations to allow remote work. The cloud supports distributed workforces and streamlines business processes, but it also exposes companies to network-based threats. Many organizations store sensitive data with third parties accessed online.

    The cloud security stack can easily become siloed, with team members unsure of their responsibilities and overlooking critical processes. A siloed stack is more labor-intensive and harder to track because the security team uses multiple security systems. It can also create alert fatigue, making it hard to identify threats. 

    While employees mostly work in the cloud, security efforts often focus on the data center. SASE shifts the focus to the cloud while ensuring seamless integration between security services.

    With SASE, a single provider delivers the entire security stack, ensuring it functions as a unit. For instance, an SWG uses threat intelligence data to block suspicious traffic, sending unidentified files to a sandbox for testing. The security team can manage the entire stack from one intuitive interface. 

    Most activities occur at the edge—SASE secures the edge using an identity-driven approach. It is also cloud-native, ensuring a seamless experience. 

    Impact: How SASE Will Promote DevSecOps Adoption

    SASE provides the following advantages for adopting DevSecOps.

    Facilitating Collaboration 

    SASE helps reduce the challenges involved in cross-team collaboration. Essentially, SASE combines network security with WAN optimization. Modern DevOps teams are physically separate but must work together, requiring reliable and secure connections between team members. 

    The DevOps approach emphasizes time-to-market, so DevOps teams look for ways to accelerate the CI/CD cycle and push releases faster. An important part of the process is reducing the DevOps team’s reliance on the network and security teams. SASE solutions help optimize performance and enhance security, so the DevOps team doesn’t have to wait for the infrastructure team to configure resources. SASE gives DevOps teams the necessary control and operational cadence without compromising security or performance.

    Enhanced Networking

    SASE can improve the overall network performance by providing integrated failover and load balancing capabilities. DevOps teams must have reliable connectivity and cannot tolerate disruptions when deploying new software or fixing bugs. Fast, reliable application performance is key to the DevOps workflow. 

    The SASE architecture improves the networking, ensuring the organization’s edge devices, cloud resources, data center and remote users remain connected. The DevOps team doesn’t have to handle the infrastructure because it is self-healing, fully optimized, and secure. The solution automatically switches to another path if a line fails or a path becomes congested.

    Security By Default

    SASE protects DevOps projects with built-in security features. When implemented properly, it integrates many security technologies into the network stack. The DevOps team doesn’t have to worry about attackers intercepting sensitive information. Every security service shares the same, unified context to increase visibility and fill gaps that are often present in traditional security architectures. SASE mitigates the vulnerabilities exploited by attackers using NGFW, SWG, IPS, MDR and antivirus services in a single architecture.

    SASE can secure internal applications and their interactions, reducing the burden on the DevSecOps team. Applications running on a SASE-based SD-WAN benefit from the added protection of zero-trust network access (ZTNA) and software-defined perimeter (SDP). These technologies help ensure that all interactions between applications and endpoints are secure. 

    Proprietary apps are often too sensitive to expose to the public Internet. SASE secures these applications by obfuscating traffic, securing all entry points with NGFW, and restricting access with zero-trust network architecture. It constantly inspects all internal application traffic for cybersecurity threats. 

    Conclusion

    In this article, I explained the basics of SASE, which packages multiple networking and security solutions into one managed service. 

    SASE is giving organizations a new level of flexibility and agility with regard to their core infrastructure and is introducing the concept of security-by-design. Instead of fighting hard to “secure all the things,” we are moving nearer to a world where the “grid” our organization operates on is secure by default. This won’t make DevSecOps any less important. But it will allow us to build our applications and services within a secure, controlled hybrid environment.

  • Common RDS Misconfigurations DevSecOps Teams Should Know

    Common RDS Misconfigurations DevSecOps Teams Should Know

    Relational databases have become the option of choice for organizations wishing to streamline and scale the use, storage and retrieval of data. Many organizations choose AWS Relational Database Service (RDS) to forego the resource-intensive tasks related to database administration including management and continuous oversight. RDS is a fully managed service that simplifies and automates these processes, making it easy to set up, operate and manage relational databases in the cloud—including MySQL, PostgreSQL, MariaDB or Aurora—and their various time-consuming activities. Reducing costs and automating processes makes significant business sense and allows organizations to focus on performance, scalability and cost-effectiveness as data grows.

    That said, AWS is not the owner or the party responsible for securing your data—this duty remains in the hands of the organization. As the cloud provider, AWS does offer an impressive suite of security measures for protecting the infrastructure that runs its cloud services, including access controls, database snapshots and encryption. Their policies, however, clearly state that safeguarding data is within the responsibility of the organization and, as the moderator of your environment, you will be accountable for what occurs within it.

    The following are the six most common RDS misconfigurations related to security and compliance that DevSecOps teams should be aware of to secure their data stores and organizational assets.

    Broken Geo-Trust (aka Data Sovereignty): RDS provides the convenient option to distribute data across various AWS regions. There are various benefits to this data migration including minimizing latency, disaster recovery capabilities and scaling operations. However, the security and governance risks of cross-geo replication may significantly outweigh these benefits. A common misconfiguration includes migrating replicas or storing backups and snapshots in another location. When sensitive data travels and is stored in another geographic location, the organization may be at risk of violating international compliance requirements such as Schrems II (for EU-to-U.S. data transfer). Additionally, data traveling to various locations may not be visible to security teams or managed by DevOps teams—without a continuously updated inventory, data will spread unobstructed and ungoverned. 

    The screenshot below displays a copy-snapshot operation of a U.S.-based RDS datastore to an EU region.

     

    Inadequate Retention Periods: AWS allows organizations to retain database instances for a specific period of time as configured by the user. A common misconfiguration of this feature is the existence of unmonitored standalone snapshots, short-lived backups and a failure to permanently delete records. Organizations that retain records for a long period of time may be in breach of their GDPR obligations, whereas short-lived backups may jeopardize the organization’s ability to recover critical data in case of data loss or a ransomware attack. Clear guidelines and open communication between DevOps teams and compliance leads is the first step toward a healthy environment.

    The screenshot below presents a recommended and comprehensive backup retention period configuration from an RDS datastore creation process.

    Exposed Resources (Network Access): Publicly accessible database ports and RDS instances are a lucrative configuration loophole for malicious actors. Common misconfigurations may cause RDS database snapshots to be publicly accessible, thus providing unauthenticated users with privileges to access and abuse it through brute-force attacks, known CVEs and DDoS attacks—thereby exposing sensitive data. This risk will also impact the organization’s ability to comply with international regulatory requirements and should be a high-priority configuration when creating and maintaining such resources.

    The screenshot below presents recommended network (public) access and default port configuration from an RDS datastore creation process.

    Weak Encryption: Encryption of sensitive data—both at rest and in transit—is a necessary security baseline to ensure the integrity and confidentiality of organizational data and make it inaccessible to unauthorized users. Common encryption misconfigurations may include implementing inadequate encryption for communication channels such as TLSv1.2 (and higher), weak cipher suites or untrusted CA which may lead to a false sense of security. For data at rest, another common misstep is a lack of key rotation or exposure of the encryption key to unauthorized entities.

    The screenshot below presents the recommended basic encryption-at-rest configuration to be enforced when creating an RDS datastore.

    The screenshot below presents recommended basic encryption-in-transit configuration to be enforced when creating an RDS datastore.

    Improper Authentication & Authorization (RBAC): A cornerstone of adequate data security hygiene is ensuring that access is only associated with a unique account based on the principle of least-privilege, using strong identification methods with appropriate justification. With RDS, users may not use IAM accounts, provide over-privileged access and permissions to either the main instance or to backups and refrain from implementing a user-access quarterly review.

    The screenshot below presents the recommended authentication configuration to be enforced when creating an RDS datastore.

    Incomplete Audits: Visibility cannot be considered a point-in-time activity. Monitoring of access and use of sensitive data is an essential component of tracking organizational assets and will provide crucial information in case of an incident or potential data breach. Incomplete or misplaced audit records including login/logout events, short-lived audits or leakage of sensitive data from RDS to audit logs increases the risk. 

    The screenshot below presents the recommended audit and log configurations when creating an RDS datastore.

    Misconfigurations and single points of failure in cloud environments may be unavoidable for all organizations, especially those operating at scale, due to knowledge gaps, high velocity of data and changes and a lack of visibility as the amount of data increases. While the security baseline may be covered by RDS configurations, these are only the minimum required to protect your environment. DevSecOps teams are encouraged to work closely with their compliance leads to ensure that customer data is secured; leveraging RDS for its benefits is a complex and entirely more substantial responsibility. Organizations must view their data as an inherent part of their internal assets. As its owner, they should create appropriate ecosystems that allow continuous oversight and monitoring of the data, gaps that may arise and, most importantly, the controls in place to secure it. 

  • What is DevSecOps?

    What is DevSecOps?

    While traditional development practices have long separated security and compliance, DevSecOps as a series of best practices integrates security into every phase of the DevOps software development life cycle. DevSecOps introduces and automates security in the earlier phases of the software development life cycle rather than bolting it on at the end. The approach saves money, saves time on tedious manual tasks, helps organizations meet regulatory compliance requirements and significantly reduces the risk of critical security bugs being found after an application’s final build. DevSecOps promotes the use of, for example, active penetration testing, security audits and other security tools within an agile development process.

    The goal of DevSecOps is to create a collaborative environment between developers and security professionals that enables organizations to build secure code faster and more easily. By emphasizing security from the very beginning of the process, it becomes a priority in the app dev process rather than an afterthought. Over time, developers become more familiar with the common weaknesses in software that today result in more insecure applications being deployed than most anyone really wants to admit. The end goal is to create secure applications by making it easier for developers, security experts and operations professionals to collaborate throughout every stage of application development.

    Minimizing Application Vulnerabilities

    It may seem tedious and expensive to integrate security into the development process, but it’s become essential for organizations to embrace DevSecOps to minimize the number of application vulnerabilities that cybercriminals might exploit. When applied throughout the development process, scanning and reporting can take place within a matter of minutes rather than holding up deployment at the end of the process to review the entirety of an application.

    Leaving security to either the end of the application development process or, worse yet, after an application has been deployed only increases the total cost of ownership. It’s much more expensive to remediate a vulnerability after an application has been deployed than it is to address an issue during the application development process.

    Implementing DevSecOps requires organizations to set up workflows that are managed via a continuous integration/continuous delivery (CI/CD) platform. Most critically, developers must understand the role security plays in enabling organizations to identify vulnerabilities as early as possible in the application development life cycle.

    Inserting security audits and penetration testing into the development process, for example, helps ensure the security of an application. When changes are made in a project, scanning, architecture reviews and penetration testing can be triggered within the development flow to save time and resources.

    DevSecOps Adoption

    However, there are many technical and cultural challenges ranging from tool integration to a lack of trust between developers and security teams that can impede the adoption of DevSecOps. Security professionals are tasked with identifying and preventing vulnerabilities in applications. Acceptance test criteria, user designs and threat models should be created by security professionals. The development team then needs to define a code review system to ensure uniformity.

    Despite those concerns, the most important thing is to simply get started. Ideally, development and security teams should work together to create a safe application development and software development environment. There is no need to create separate teams or apply different policies.

    The biggest benefit of DevSecOps is that it eliminates silos between development and operations. As a result, software engineers integrate cybersecurity processes from the start of the development process. This includes ensuring that every component, configuration item, and installation process is securely patched and documented. This concept of shifting security to the left allows the security team to identify and remediate security threats early on.

    In the longer term, however, adopting DevSecOps best practices will ensure security remains a top priority in the wake of a series of high-profile cybersecurity breaches. In short, there is now more focus on DevSecOps with the goal of securing software supply chains.

  • DevSecOps Practices Gap Assessment

    DevSecOps Practices Gap Assessment

    DevSecOps practices are essential to deliver software safely and securely withinDevOps value streams.

    To get the maximum security protection from DevSecOps, it is important to use recommended best practices, inclusive of people, processes and technologies. A gap assessment is a great way to efficiently evaluate an organization’s practices for DevSecOps and determine a strategy for improvement. Gap analysis provides valuable inputs for formulating a strategy and roadmap to improve a topic including DevSecOps.

    My SlideShare Gap Survey, Assessment and Analysis For DevSecOps explains how my 9 Pillars Gap Assessment Tool greatly speeds up the gap survey, gap assessment and gap analysis process for DevSecOps.

    It is important to clarify a few definitions for these purposes, because I have found that different people and organizations use these terms differently. In this blog, and in my consulting work, I use the following definitions:

    • Gap survey is discovery tool used to collect information about the current state of practices for a topic.
    • Gap assessment is a process to determine differences (gaps) between current practices and recommended practices for a topic. Gap assessment is also used to refer to the entire collection of activities in this list.
    • Gap assessment workshop is a meeting in which the gap assessment is validated prior to gap analysis.
    • Gap analysis is the process of determining priorities for reducing the gaps found during a gap assessment.
    • Gap assessment tool is software that helps perform gap surveys, gap assessments and gap analysis.

    For those that want to dig deeper on this topic, additional definitions and contextual information related to the way I do gap assessments are clarified in my book Engineering DevOps.

    I define a seven step process for gap assessments. The steps are as follows:

    1. Pick a topic to analyze. The same processes and tools can be applied equally well to almost any topic.
    2. Determine recommended practices for the topic. Something that is worth doing a gap assessment for, such as DevSecOps, will normally be fairly complex with tens, if not hundreds, of practices. Categorize the practices into groupings (I call the groups “pillars”) to make the list of practices more understandable and meaningful. Doing this will require some research and work. For example, I have a database of practices and pillars for DevOps, continuous testing, DevSecOps and SRE and some other topics such as containers.
    3. Enter the chosen practices into a gap assessment tool. The tool can be a simple survey tool you create, a commercial survey tool or something custom-made.
    4. Determine who needs to be included in the gap survey.
    5. Collect data using the gap survey.
    6. Perform a gap assessment.
    7. Perform a gap analysis.

    Let’s take a look at the above seven steps for DevSecOps.

    Step 1: Pick a Topic to Analyze

    For our purposes here, the topic is DevSecOps.

    Step 2: Determine Recommended Practices for DevSecOps

    For an example DevSecOps assessment, I used the practices under nine practices categories described in a blog that I co-authored called 9 Pillars of Continuous Security Best Practices. The nine practice category pillars are:

    • Leadership
    • Collaborative culture
    • Design for DevOps
    • Continuous integration
    • Continuous testing
    • Continuous monitoring
    • Elastic infrastructure
    • Continuous delivery
    • Continuous security

    Step 3: Enter the Selected Practices into a Gap Assessment Tool

    You can find and download a free gap assessment tool, pre-loaded with a sample of DevSecOps practices in a file called DevSecOps Assessment, from one of the resource pages found on my website, EngineeringDevOps. You can edit the practices categories and add/delete practices from each category if you prefer to make changes.

    Step 4: Determine Who to Include in the Gap Survey

    For the gap analysis to be comprehensive, people in roles that are affected by container practices need to be surveyed, or at least represented, to ensure their perspectives are included. Some example roles that are typically included:

    • Business leaders – because leaders influence culture and budgets for DevSecOps.
    • Developers – because developers need to design in accordance with DevSecOps practices.
    • Project owners – because they influence product work priorities.
    • QA testers – because they need to test in accordance with DevSecOps practices.
    • Ops – because DevSecOps practices affect operations.
    • Security – because DevSecOps practices affect security practices.

    The survey can be conducted for an individual application, a group of applications or all the applications in the enterprise. However, it is important that the gap assessment and gap analysis be performed on the organizational segment that is being targeted for improvement.

    Step 5: Collect Data Using the Gap Survey

    A gap survey should allow each surveyed person to enter an “Importance Level” score, a “Practice Level” score and comments for each practice. All this information is essential for the gap assessment and gap analysis. In the gap survey included in in my gap assessment tool, survey respondents are asked to score the importance of each practice as one of 0=not relevant, 1=not important, 2=nice to have, 3=important, 4=very important or 5=critical. Practice-level choices are 0=not sure, 1=rarely, if ever, 2= sometimes, 3=most of the time, 4=always or 5=we are good at this. Comments that are relevant to qualify or explain the scores entered for each practice should also be entered, especially if there is any doubt or ambiguity.

    Step 6: Perform a Gap Assessment

    The gap assessment process requires all the practices scores collected from the surveys to be collected and assembled to calculate an aggregate set of scores. Gap scores are calculated using a formula that weights each practice level score with the corresponding importance level score. A visual representation helps to identify practices areas and individual practices that have the highest, most important gaps.

    No matter how professionally written the practices and score definitions are, it is not unusual for some people to misunderstand and to enter scores that they would not have otherwise. For this reason, it is important to ensure that the data collected is validated before conducting the gap analysis. The preferred approach is to conduct a gap assessment workshop with key representatives from each role that participated in the survey. During the workshop, the scores for each practice that have a high deviation between survey responses are discussed and, if necessary, adjusted.

    Step 7: Perform a Gap Analysis

    The gap analysis process involves extracting the high gap practices and tagging and ranking each of them against solution categories that are determined by a consultant or topic expert.

    The result of the gap analysis indicates where solution strategies and implementation roadmaps need to be focused to reduce the most important gaps.

    What This Means

    While is it clear that DevOps offers immense value for software deployment, the adherence to best practices for DevSecOps is essential to reduce risk and assure security. Each organization is different, and has different security postures. The specific practices, security tools and metrics that are appropriate may vary according to a risk assessment for each organization. This blog explained a gap assessment approach, which uses my nine pillars of best practices for DevSecOps. My free DevSecOps assessment tool facilitates a gap analysis for DevSecOps and priorities to improve DevSecOps practices for an organization.