devopsy.kinsta.cloud

Tag: shift left

  • Why It’s Time for Site Reliability Engineering to Shift Left

    By adopting a multilevel approach to site reliability engineering and arming your team with the right tools, you can unleash benefits that impact the entire service-delivery continuum

    In today’s application-driven economy, the infrastructure supporting business-critical applications has never been more important. In response, many companies are recruiting site reliability engineering (SRE) specialists to help them improve reliability, availability, latency and a host of other metrics that impact customer satisfaction. These vital new people resources are focused on keeping sites and services running in peak form.

    There are clear limitations to this operations focus, though. A service is made up of many application components that can impact business-critical services. How do you ensure reliability is baked into each app and each code change if your engineers focus only on backend performance?

    Some trailblazers are beginning to tackle this issue head-on, tasking their SREs with taking on new roles that support key stages of the DevOps life cycle. The goal is to take early, proactive steps to ensure quality and reliability are built in from the beginning.

    A Path Pioneered by Test Teams

    To understand why this “shift left” is so important, consider recent revolutionary changes in the software testing function. Not that long ago, testing was considered a distinct phase in the software life cycle, timed to begin well after the work of application developers was done. Testing Centers of Excellence uncovered defects and passed code back to the development team for rework.

    As developers moved to agile sprints, though, this approach to testing quickly became a bottleneck. By the time Centers of Excellence uncovered issues, developers had moved on to other projects. In response, new continuous testing programs emerged, staffed by a new breed of software development engineers who had honed their testing skills.

    These individuals are now embedded with development teams to ensure applications are built better from the start. Open source test automation tools help them test early and often, without impeding agile delivery schedules.

    It’s important to note that Testing Centers of Excellence haven’t gone away. Instead, they have taken on a broader leadership role and are now responsible for coordinating testing across the enterprise in support of continuous software integration and delivery.

    A 3-Level Model for SRE

    There is much that SRE teams can learn from the experiences of their testing colleagues. To produce optimal results, it is important to integrate reliability experts into your organization’s overarching agile framework. Consider adopting the following three-level model that shifts the function to the left and integrates skilled engineers at key points in the DevOps life cycle:

    1. Application level. Embed SREs with development and testing teams to ensure application components and new releases won’t disrupt reliability. These individuals focus on application-level service objectives, error budgets and integration into the DevOps pipeline.
    2. System level. Assign SREs to focus on the applications in your organization’s release train. These individuals support release and launch coordination, evaluate system architecture readiness and ensure your organization meets systemwide service-level objectives.
    3. Enterprise level. Establish a Site Reliability Engineering Center of Excellence, staffed by engineers who oversee the governance of your enterprise architecture. These individuals establish best practices and select the tools and resources required to support your site reliability function companywide.

    An Expanded Toolset

    To support this broadened role, you will need tools that can support your engineers across the entire DevOps life cycle. You will need to be able to see and track issues engineers uncover and to evaluate system-level readiness and performance against your service-level objectives. You will also need a big-picture view that spans activity across the entire enterprise.

    Fortunately, a new generation of solutions is now available to help, powered by artificial intelligence, machine learning and intelligent automation. These resources can help your team process massive amounts of data from disparate toolsets and turn that data into actional insights. As a result, you’ll have all the lifecycle analytics you need to be effective in your new and broadened role.

    SRE and Shift Left: Broad New Benefits

    By adopting a multilevel approach to sire reliability engineering and arming your team with the right tools, you can unleash benefits that impact the entire service-delivery continuum.

    You can build a continuous cycle of feedback, collaboration and governance that spans design, development and the launch and operation of new services. You can better manage configuration changes, service levels and error budgets. You can get a clearer view of application reliability and production readiness to guide planning initiatives and to help you prioritize investments.  And you can build better-informed business cases to move your organization forward. Shifting left is clearly a win-win move.

  • The History of Computing Part 4: Testing

    The History of Computing Part 4: Testing

  • GitLab Adds Fuzz Testing to DevSecOps Toolbox

    GitLab Adds Fuzz Testing to DevSecOps Toolbox

    GitLab today announced it has acquired Peach Tech, a provider of protocol fuzz testing and dynamic application security testing (DAST) API testing tools, and Fuzzit, a continuous fuzz testing tool, as part of its efforts to advance the adoption of best DevSecOps practices.

    David DeSanto, director of product for GitLab Secure & Defend, said the two acquisitions should make it easier for DevOps teams to incorporate both whitebox and blackbox fuzz testing techniques for security testing much earlier in the application development and deployment process.

    Fuzz testing is an automated technique that involves providing invalid, unexpected or random data as inputs to software, which is then monitored to see what happens—if it, for example, crashes or a memory leak is created.

    Peach Tech adds Peach Fuzzer, an automated security testing platform that employs definition files known as Peach Pits to generate the fuzzed data consumed by the test target along with a framework for automating the web application programming interface (API) security testing process.

    Fuzzit provides a service that enables DevOps teams to continuously generate fuzz tests and correlate crashes in a way that can be integrated within a continuous integration/continuous delivery (CI/CD) workflow.

    Once Peach Tech and Fuzzit technologies are fully integrated with each other and the GitLab platform, DeSanto said GitLab Secure customers will be able to automate myriad tasks, from security testing to vulnerability management and remediation.

    GitLab will also employ technologies from both companies to further its ambitions to drive the adoption of interactive application security testing (IAST). The goal is to not only make it easier for developers to employ DevSecOps tools but also understand what issues are being created as applications are developed, said DeSanto. That approach should reduce the number of instances where development teams are continuously making the same mistakes across multiple application development projects, he noted.

    The further left cybersecurity testing is shifted the less stress there will be on chronically short-staffed cybersecurity teams. The challenge is that while most organizations recognize the potential benefits of DevSecOps there hasn’t been much progress in educating developers on what issues to look for and providing them the tools needed to discover and remediate vulnerabilities.

    There is, of course, no silver bullet when it comes to cybersecurity. As long as humans write code there always will be potential issues. However, many more routine cybersecurity issues should be addressed long before an application is deployed within a production environment. To achieve that goal organizations are providing developers with tools that identify cybersecurity issues as they write code in addition to incorporating more security testing into their CI/CD workflows.

    Of course, GitLab is not the only provider of a CI/CD platform focusing on how to foster the adoption of best DevSecOps practices. There’s clearly a race to embed security testing tools within CI/CD platforms that should advance adoption for DevSecOps, if for no other reason than they are becoming easier for developers to discover and employ.

  • Using this Time to Optimize Your Dev Team’s Workflow

    Using this Time to Optimize Your Dev Team’s Workflow

    As Andy Warhol once said, “They always say time changes things, but you actually have to change them yourself.” This more than ever resonates with the change that companies have found themselves experiencing of late. The more the world embraces digital methods of work, the more that change becomes paramount to a successful workflow. It is crucial to adapt, whether that means throwing out the old or bringing in the new — or a mix of both. 

    The current global pandemic has forced companies to reconsider how they operate, and it’s no different for their development teams who now find themselves distributed. So the question becomes: How do you go about using this time as an opportunity to optimize your team’s workflow?

    By making the necessary changes, you can not only increase productivity, but also make your team happier. As the saying goes, “Happy devs, happy life.” Let’s look at automation, independence and understandability as key components of your digital transformation. 

    What’s Killing Your Team’s Productivity 

    The Problem: Too Much Bureaucracy

    Being too dependent on management or your colleagues is often a bottleneck at many companies, especially larger traditional ones. When we were all in offices, this problem could be mitigated more easily — but today, things are shifting toward more ownership, and having everyone distributed means you need to be able to get the job done yourself.

    The Solution: Shift-Left

    Bureaucracy shouldn’t be in place just for bureaucracy’s sake. While the goal of those processes are typically risk mitigation and governance, DevOps advocates have been arguing that modern tools and techniques allow shifting-left much of that burden directly onto developers. Use this time to empower developers to build in alternative safeguards relying on automation, self-service and measurement instead of change boards and forms.

    The Problem: Status Meetings

    Status meetings are the bane of all developers’s lives. Nobody will argue that they’re not important, but who wants to sit through meetings when you can be spending time elsewhere? — for instance, at your desk, sipping a nice cup of coffee while working on your code and finding that elusive bug.

    The Solution: Asynchronous Communications

    What used to be done with lots of in-person status meetings doesn’t always translate well to a video conference — water cooler talk just isn’t the same via teleconference. While it’s important to try and maintain that personal touch, it’s even more important to enable asynchronous communication methods as much as possible — both free-form (such as email) as well as structured (such as ticket management). Moving to this new mode of operation requires developers to be more independent. This is another place where automation can play a huge role, formalizing tribal knowledge into scripts and tools, making them easily accessible for all.

    The Problem: Lack of Data

    How many hours have you spent staring into the great abyss of code, hoping and praying that you’ll be able to deploy soon? You’re not alone, we’ve all been there, done that. Waiting for deployments is par for the course of living life as a dev. The source of this long wait? A small, missing piece of data. And this need for data creates what I like to call the engineer’s dilemma: Is it better to fly slow but have the data I need, or fly fast but perhaps be making worse decisions due to a lack of data?

    The Solution: Understandability

    Understandability tools allow quick access to data in real time. This results in shorter, more efficient workflows, which in turn improves team velocity and code quality substantially. Understandability is not the same thing as observability. Think of it like this: Observability helps teams quickly identify where a problem is, but you still need a tool that can quickly fetch the data in order to solve the problem. In other words, if data is the new oil, go find the understandability tool that you think is the best drill.

    Conclusion

    Change is not a concept most like. But now that it’s happening anyway, it creates an opportunity to introduce a healthier, more productive workflow. Grab that cup of coffee and ask yourself: What change would benefit us most? Find it, implement it and watch as your distributed teams become a smooth-sailing ship in no time.

  • Who’s Responsible for Security? Apparently, It Depends

    Who’s Responsible for Security? Apparently, It Depends

    More than 10 years after organizations began implementing DevOps, responsibility for security still resembles the proverbial chicken and egg dilemma.

    GitLab’s 2020 Global DevSecOps Survey asked developers, security team members, operations pros and testers about sole responsibility for security in their organizations.

    About 28% of developers, 33% of security teams, 21% of ops pros and 23% of testers said responsibility for security rested only on their shoulders. At the same time, 29% of security teams said everyone was responsible, nearly as many as said they had sole ownership.

    Confused yet? So were many of our survey respondents, who had a lot to say about the fluid – and frustrating – nature of DevSecOps.

    “The team is trusted to do its own security research and implementation. We don’t know how good or bad we are.”

    “I am the only one who actually cares about security in my organization.”

    “I regularly put security suggestions in the box of suggestions, only to be ignored.’”

    “There’s a security team, but it doesn’t involve face to face with us, the dev team. So we just run the dev process without counting on them.”

    The Blame Game

    There’s a long history of developers and security pros not seeing eye to eye. In GitLab’s 2019 Developer Survey security pros were very expressive on the subject of developers simply not doing enough to enable security. Developers were equally unhappy, citing security’s “heavy-handed approach.”

    This year, we drilled down further to see if we could understand why dev and sec continue to see the world differently.

    Differences between the teams quickly became apparent. According to the survey findings,  65% of security team members told us their organizations have shifted security left. But the devil is in the details, and the details do not really support a shift left.

    A solid majority of developers are not running SAST, DAST or container scans, and only about half conduct compliance scans. Even if the scans are run, less than 19% put SAST results into a pipeline report a developer can access. Dynamic application security testing (DAST) fares even worse – less than 14% of companies gave developers access to those reports.

    So, developers don’t have easy access to critical data. On the other hand, security pros are frustrated that developers continue to either miss bugs altogether or find them too late in the process. Over half of security respondents (61%) agreed at some level that vulnerabilities were mostly found by security pros (not developers) after code is merged in a test environment (which is relatively late in the process). In other words, when asked how developers find bugs versus security teams, 93% gave developers credit for discovering only 25% or less of the bugs to be found in existing code, leaving three-quarters of the bugs for security to find at a later stage in the process.

    And as if that wasn’t sufficiently frustrating, 69% of security team members complained it was difficult to get developers to remediate bugs, even if their organizations included security as a developer performance metric.

    How DevSecOps Can Work

    Clearly, there is work to be done to get developers and security on the same page, but we are seeing a few glimmers of hope. Security pros are not quite the lone wolves they once were; many told us that DevSecOps has brought a welcome change to their responsibilities. Nearly 28% reported being part of a cross-functional team focused on security and almost the same number (27%) said they were more hands-on and involved in the day-to-day development activities. Almost 23% said they were now focused more on compliance and about 20% said they did not see any changes in their roles.

    In perhaps the most significant (and promising) finding, GitLab asked what skills would be most important to a security professional’s future, the majority (almost 28%) said soft skills like communication and collaboration. Interestingly enough, a majority of their developer counterparts agreed with that.

    So, while no one agrees just yet on who owns security or even how to prioritize security, it’s encouraging that both developers and security pros realize they need to prioritize communication and collaboration.

    At least one respondent reports success in figuring it all out:

    “We don’t have separate security, developers and operations; we are DevSecOps (and more).”

  • The DevOps Sweet Spot: Inserting Security at Pull Requests (Part 2)

    The DevOps Sweet Spot: Inserting Security at Pull Requests (Part 2)

    In part one of this two-part series, I explored how organizations can more effectively automate security quality decisions and discard doing automation for automation’s sake. I shared why security scans need to be faster, more reliable and comprehensive. Only then can security be meaningfully automated into developer workflows without slowing them down.

    But, the other part of this is understanding where these security scans should take place throughout the SDLC. Why? Because inserting security too early or too late in development and pre-production can have drastic impacts on remediation efficiency, developer productivity and more. 

    Shifting Security as Far Left as Pull Requests

    Identifying vulnerabilities once they’re in production is the riskiest, as well as the most time-consuming and expensive remediation. Working in pre-production test environments or builds reduces the risk, but not much of the time or efficiency in remediation. Conversely, inserting code analysis into developer IDE’s is too early. While in theory the IDE could be a good place for security feedback, in practice, it slows down the developer’s machine and comes at a huge cost of productivity.

    Instead, commits and pull requests are the ideal place to insert security because it delivers the right vulnerability information to the right developer at the right time. Combine this with integrations into ticketing and other systems and the full developer workflow can be meaningfully automated.

    Simply by getting the right developer, the right vulnerabilities information breaks down one of the biggest challenges in AppSec. Developers typically outnumber AppSec team members by 50-1 or more—hence a security scan that generates 100 vulnerabilities creates a tremendous amount of work for a single AppSec professional. However, assigned to the right developers, at an average of two per person, the challenge immediately becomes more manageable. Still accuracy matters because, while the burden may be spread out, developers triaging false positives is an expensive resource focusing on a low value task.

    Getting developers security feedback at the right time is also vitally important. When developers get immediate security feedback, vulnerabilities become easier to fix because the code is still fresh in their mind. Furthermore, fixing vulnerabilities early has compounding benefits. Since insecure code never goes into production, not only is the attack surface reduced, but additional code that is dependent on the vulnerability never gets written. This minimizes the most expensive and time-consuming security fixes, which require not only fixing the underlying vulnerability, but also rewriting dependent code. Best of all, with immediate, regular, comprehensive and accurate security feedback, developers will ultimately learn and adopt more secure coding practices overtime.

    Lastly, by inserting security at the commit or pull request, security and developers can establish a shared responsibility model on more realistic terms. When security can commit to accuracy and timely KPIs, developers can commit to triaging and fixing vulnerabilities faster. This reduces MTTR, puts a downward trend on defect density and reduces the application’s overall attack surface. It also reflects the realities that AppSec professionals have a limited ability to triage vulnerabilities, because they don’t know the code intimately and that only developers can fix the underlying vulnerabilities.

    By solving the fundamental challenges of speed, accuracy and comprehensiveness to deliver the right vulnerability to the right developer at the right time, security earns the ability to ask more from developers, and CISOs and CTOs can jointly accept responsibility for protecting applications and data.

    The rate at which software is being created and shipped isn’t slowing down, but many organizations have struggled to find where security most effectively fits into this process. By inserting security at the pull request, not only can developers identify and remediate vulnerabilities faster and more accurately, they can better automate security quality decisions. By taking this approach, organizations are fundamentally changing how engineering and security collaborate within enterprises.

    — Chetan Conikee

  • Better Apps and Better Security When You Shift Left

    Better Apps and Better Security When You Shift Left

    Tens of thousands of people and hundreds of cybersecurity vendors descended on San Francisco at the end of April. While the RSA Conference was the primary draw, there are a number of peripheral events that go on throughout the week as well, such as the Cloud Security Alliance Summit, the CIO/CISO Interchange, BSides San Francisco and the Qualys Security Conference.

    I was able to attend some of the Qualys Security Conference and I had the opportunity to see Alex Mandernack, security solution architect for product management at Qualys, presenting on the need to shift left when it comes to cybersecurity.

    Mandernack outlined some of the issues organizations face today when it comes to security. Migrating to the cloud and embracing DevOps culture means more ephemeral, elastic environments and compressed development time frames. He pointed out that these trends make security more challenging, but also described the opportunity they present to change our approach to streamline and improve security.

    The Traditional Pipeline is Broken

    The traditional model of application development is much more linear. Each app team builds their own image—often in a silo or vacuum disconnected from other teams. Penetration testing is conducted on a sporadic or infrequent basis, and eventually the app is deployed. Vulnerability scans are run on the app in production, and issues or deficiencies are reported back to the developers to address or incorporate into the next build.

    The process is slow and cumbersome. It also has the potential to introduce redundancies that waste resources and make the organization less efficient. As companies embrace DevOps and move to the cloud, the traditional development pipeline simply doesn’t work—especially not for security.

    DevOps, and Cloud, and Containers — Oh My!

    The cloud and DevOps fundamentally change the development lifecycle. Development time frames are compressed, and the process is a self-feeding, iterative circle rather than a repeating linear approach. The traditional approach of identifying and resolving security issues after an application is deployed won’t work in a DevOps environment because by the time issues are identified and fixed, the app itself may have already moved on to the next version.

    Cybersecurity and the development pipeline have enough challenges with the cloud and DevOps, but there is also a newer technology trend that exacerbates the problem—containers. Containers are designed to get code quickly and to operate fast. They are also built for scalability—spawning and spinning down hundreds or thousands of containers constantly to keep pace with demand.

    There is a diverse array of tools and platforms associated with cloud, DevOps and containers. Organizations often employ a complex collection comprised of some combination of AWS, Azure, Docker, Kubernetes, OpenShift and others. The result can quickly become a black hole when it comes to security—which is why it’s important to push security left into the CI/CD pipeline.

    Shift Left to Help Security Teams Do Better

    In a DevOps culture, developers and security teams need to think about security sooner. It’s important to get the security tools into the process earlier. Thankfully, with the DevOps lifecycle and the tools commonly used within a DevOps environment, it can be done.

    For starters, companies should build a golden image. Developers shouldn’t have to patch and update the base operating system before they even start developing. The golden image takes a baseline operating system such as Ubuntu or CentOS, and completely patches and configures it so everyone has a standard, consistent image to develop on.

    With the golden image in place, the next step in shifting security left is to implement testing and scanning in the CI/CD pipeline. Put vulnerability information at the fingertips of developers as they’re developing and implement vulnerability gates in the pipeline to ensure that applications that don’t comply with policies and meet minimum requirements are not allowed to be deployed.

    New Role of the Security Team

    Part of shifting security left includes providing tools that make security self-service for the DevOps team. Automating actions with scripting, APIs and CI plugins ensures that security is simplified and streamlined to provide value for developers.

    In this shift left scenario, the security team has to redefine its role in the process. The security team is still vital, but rather than being the police or a roadblock in the development process, the role of security focuses on verifying and auditing the process. The security framework should have dashboards and live data that enable the security team to monitor activity and identify trends that may need further attention.

    Better Security, Faster

    There is often conflict between developers and security teams, but there doesn’t need to be. Mandernack stressed that developers don’t want to create insecure apps either.

    Shifting security to the left into the CI/CD pipeline streamlines the whole process. Ultimately, the result is higher quality, more secure applications that are developed faster.

    — Tony Bradley

  • Survey Sees Little Progress in Drive to Shift Testing Left

    Survey Sees Little Progress in Drive to Shift Testing Left

    It looks like the drive to shift testing left toward developers to accelerate the development and deployment of applications has stalled. A survey of 102 IT professionals involved in application testing published by Perforce, a provider of testing tools, finds only 18% of organizations test applications solely within their development feature teams. The rest continue to rely on a separate team in one form or another.

    More troubling still, the survey conducted by Gateway Research finds more than half the respondents (56%) are automating less than a quarter of their test cases.

    Eran Kinsbruner, chief evangelist for Perfecto by Perforce, a set of testing tools, said the survey results make it clear that when it comes to automating testing within a DevOps environment there is still a lot of reliance on manual testing. In fact, the survey finds the rate of test automation is less than 50% on average. Almost 40% of teams are automating fewer than a quarter of their test cases, while only 9% automate three-fourths of their test cases, the survey finds.

    On average, only 14% of respondents said they are releasing code daily. Another 39% said they release code weekly, while 46% release code monthly.

    Kinsbruner said it’s clear most organizations are still engaging in a “Big Bang” approach to testing that results in most testing being conducted after large amounts of code has been merged versus being conducted by developers concurrently as code is developed. A total of 66% said they test code after a development project is ready, while 54% said they test when each build is ready. That compares to 43% who test upon each code change and 41% that test at the start of a software sprint.

    A major reason many organizations are not releasing code faster is clearly manual testing. The survey identifies manual testing as the most time-consuming element of the testing process (72%), followed by test environment setup (28%), script creation/maintenance (27%) and test cycle analysis (19%). In terms of biggest challenges organization face, achieving complete test automation (47%) tops the list, followed by test instability/false negatives (44%) and lack of scripting/coding skills (41%).

    In terms of overall priorities, survey respondents placed reducing regression testing time (46%), reducing the number of escaped defects (43%) and automated testing (43%) at the top of the list.

    It may not be possible to automate every part of the testing process, but Kinsbruner said it is clear many more organizations could be automating lower-level testing processes to accelerate application development and deployment. In fact, the survey notes 46% of respondents are looking to invest in test automation in 2020. Among organizations that are using testing tools, two-thirds are using open source software (68%), while 66% are using some type of automation framework.

    Regardless of the approach to testing, Kinsbruner said it’s clear testing teams need more visibility into the DevOps pipeline. Organizations are clearly underestimating how long it takes to thoroughly test an application, so the sooner those teams can see what is being developed the faster they can develop test suites, he said.

    Of course, there are still plenty of development teams that are giving short shrift to testing in the name of achieving delivery deadlines. The trouble with that approach, however, is the end customer all too often winds up being dissatisfied to the point where the application winds up being reject altogether. After the end of the day, nobody really wants more bad code faster.

    — Mike Vizard

  • Shifting Left – But How Far Left Do Companies Need to Go?

    Shifting Left – But How Far Left Do Companies Need to Go?

    For developers, there’s nothing more satisfying than looking at a web app or service and being able to say “I made that.” Or at least part of that. Being able to develop code that works and helps millions of people do what they need to get done is an excuse for bragging rights.

    But the opposite is also true. You don’t want to be the developer whose code inadvertently enables hackers to take control of online apps or services, for instance. There are many examples of these kinds of errors. Hackers are better and more sophisticated than ever, and no programmer wants to be the culprit in the ever-increasing number of attacks based on poor coding practices.

    Where and when do errors like these creep in? It could actually be at any stage of development. Vulnerable code could be the basis for a main module in an app, including in the very early stages of development. Once implemented, bad code travels through all stages of development, making apps vulnerable to exploits. Hence the importance of shifting left–deploying security at as early a stage in the process of code creation as possible.

    What exactly does shifting left mean in the context of code development today? Tools need to be integrated in as early in the process of development as possible, and at every stage of the software development life cycle. Today, programmers will work on code and commit their changes several times a day. They need to be able to examine that code for security issues before committing that code to the repository that other teams will be basing their work on. That, of course, is what they would do if they were checking for functional defects, and the same must be done to exclude insecure code.

    What’s the best approach to shifting left in the early stages of development? Developers need tools that can supply them with actionable information, highlighting specific issues in specific lines of code. Sort of like a “spell checker” for security risks, the tools would point out the location and issue in a line of code, and even make recommendations for how to mitigate the risk.

    With that, there are some caveats that come with tools that report risks at such a granular level. Tools should be flexible enough not to over report issues. One general problem with security tools is the possibility of false positives. Security testing tools are notorious for generating very long lists of reported issues, with many of them turning out to be false positives or issues that are not critical to fix. So, to be taken seriously and provide real value, security testing tools need to effectively highlight the high-severity alerts that you cannot ignore and also separate out true vulnerability signals from noise (i.e. false positives).

    Another caveat is that other tools need to be deployed further on in the development process. When a module is completed, it becomes a building block for other modules that will eventually be part of the full program. Testing needs to be done to determine if there are security risks when modules work together. Thus, you should not consider security as shifting left, but rather expanding left, maintaining a presence alongside the development process as it moves forward. With this kind of strategy, programmers can be sure they will have those bragging rights, proudly pointing to what they built.

    — Shahar Sperling

  • Practical Approaches to Long-Term Cloud-Native Security

    Practical Approaches to Long-Term Cloud-Native Security

    There is no shortage of advice out there about how to secure modern, cloud-native workloads. By now, most developers and IT engineers who work with cloud-native deployments have heard all of the mantras about DevSecOps, shift-left security, multi-layer defenses and dynamic baselining (to name just some of the key concepts that are driving IT security conversations these days).

    One thing is to talk about security best practices and another is to design a cloud strategy that makes it not only possible but also easy to implement them. Even more challenging is planning a strategy that facilitates security best practices over the long term.

    Keep reading for tips on meeting these challenges and devising a long-term security strategy.

    Security Is a Long Game

    It’s easy to think of security as something you have to do in real time. After all, threats and attacks usually happen suddenly, and reacting to them quickly is key to preventing serious damage.

    If your security strategy centers on finding and remediating threats as they appear, you end up stuck in what is essentially a break/fix mode. You’re constantly reacting, rather than being proactive.

    A much more effective security strategy is one that minimizes the threats you face in the first place. That type of strategy requires long-term planning.

    Sure, you will always need to be prepared to detect some threats that you didn’t anticipate, and react quickly in the event a breach occurs. No security plan is perfect, and the unexpected will sometimes still happen. But by focusing as much as possible on long-term security solutions that stop most threats from materializing, you end up with a much safer and more reliable security posture.

    Building a Long-Term Security Strategy

    What does it actually take to implement a security strategy that protects you over the long term? It all boils down to four elements: data, infrastructure, processes and culture.

    Data

    For many organizations, data stored in the cloud is the workload that poses the greatest risk. It’s the reason why there is a seemingly never-ending stream of headlines about major security breaches that involve the theft of sensitive data stored in the cloud.

    Therefore, mitigating threats to data in the cloud is a critical requirement for long-term security. Some best practices in this regard include:

    • Assess your data: Data security starts with knowing what is in your data, and how sensitive the data is. Data cataloging can help with this process, but so can tools such as Amazon Macie, which helps identify personally identifiable information with cloud-based data.
    • Access control: Access control frameworks are another crucial line of defense against cloud-based data breaches. Just remember that simply enabling IAM is not enough; you must also audit IAM policies to avoid misconfigurations that could lead to a breach (which was the lesson learned by Capital One, among others).

    Infrastructure

    These days, we tend to treat infrastructure–meaning the cloud-based and/or on-premise data centers that host workloads–as a relatively generic and interchangeable part of the solution stack. But while it is true that, generally speaking, no one cloud or data center is inherently more secure than another, the way you design your infrastructure plays a key role in your ability to secure modern workloads over the long term.

    Best practices on the infrastructure front, for long-term security include:

    • Immutable infrastructure: Embrace infrastructure platforms, such as ECS or EKS, that make it easy to deploy and update applications in an immutable way. Immutable building-blocks may not work for all use cases, but where possible, they reduce the number of variables and handoffs you have to contend with in order to deploy or update an application (and the more variables and handoffs, the greater the chance of an oversight that will create a security vulnerability).
    • Access control: While IAM frameworks can help prevent some types of unauthorized access, you can also increase the security of your infrastructure using Access Control Lists. A best practice is to adopt a whitelisting approach that blocks all traffic by default, and allows only explicitly trusted hosts.
    • Avoiding bloat: Cloud-native infrastructure makes it easy to spin up virtual machines, databases or other infrastructure components that you don’t truly need, and keep them running. Doing so increases your attack surface. For that reason, identifying and shutting down unused infrastructure is critical for ensuring long-term security. It also helps cut cloud costs, but that is another topic.
    • Parity: In order for developers, ITOps and security teams to be able to communicate and coordinate effectively, they should all be working with the same types of infrastructure environments. Collaboration becomes much more difficult if, for example, you use an on-premise data center for development, then deploy production workloads to the cloud. Avoid this by striving to create parity across your infrastructure whenever possible.

    Processes

    Processes are the second key ingredient in creating a long-term security plan for cloud-native workloads. Obviously, the processes you use will reflect, in part, your particular workloads and tools. But no matter your situation, your processes should be designed with the following security goals in mind:

    • Consistency: Your IT organization may consist of different teams, each with different responsibilities and agendas. Nonetheless, to the extent possible, all teams should follow the same procedures when developing, testing, staging and deploying applications. Doing so reduces the chances of variables or oversights that can undermine security. You can help achieve this consistency by creating and enforcing IT governance procedures across the organization.
    • Shift-left: Processes are the part of your IT operation where shift-left security can have the greatest effect. Shift-left security means making security a priority from the start of the application delivery pipeline. Importantly, however (and this is a point that some organizations overlook), doing shift-left security correctly also means bolstering security operations at later stages of the pipeline, too. Don’t just shift security left and call it a day; aim to make security a primary consideration at all stages of your delivery chain.

    Culture

    Culture is something that can be difficult to formalize; indeed, if you try to stuff cultural values down your employees’ throats, you risk compromising the whole point of having an organic culture in place. Instead, you want to encourage your team members to naturally embrace values that promote a culture of security. Strategies that can help achieve that include:

    • Bug bounties: Incentivize your team to look for and address security issues by hosting bug bounties for your organization’s workloads. For this purpose, “bug” should be defined broadly to include not just security bugs within code, but any kind of configuration issue in your infrastructure, tools or applications that could lead to security vulnerabilities. That way, your bug bounties can include not just developers, but all members of the IT organization.
    • Encourage shared ownership: A culture in which each engineer owns a specific application, infrastructure or process is one that limits transparency and opportunities to address security risks. Strive instead to promote shared ownership of IT assets so each team member knows his or her work may be reviewed by others, which helps to encourage best practices and reduce security issues. In essence, these are part of the values that DevOps and DevSecOps prioritize.

    Conclusion

    By designing infrastructure, processes and cultural practices that promote security, you put your organization in a position to optimize security over the long term. Planning ahead for security is the only way to escape the break/fix cycle of responding to vulnerabilities as they are discovered, which leaves you always treading water and never pushing the needle. You won’t be able to prevent all security issues, but you can greatly reduce the number that crop up by baking security into your infrastructure, processes and culture.

    This sponsored article was written on behalf of Eplexity.

    — Chris Tozzi