devopsy.kinsta.cloud

Category: DevSecOps

  • How DevOps Powered by AI and Machine Learning Is Delivering Business Transformation

    How DevOps Powered by AI and Machine Learning Is Delivering Business Transformation

    The use of artificial intelligence (AI) and machine learning (ML) is fundamentally changing the way we think about DevOps. Most notably, it is delivering a new form of DevOps that recognizes the need to have systems that are intelligent by design and underpinned by comprehensive security (DevSecOps). For many, this will be the crucial next step if DevOps is to shorten the software development lifecycle for all connected intelligent systems, ensuring the continuous delivery of secure high-quality software.

    By now, most organizations understand DevOps is a substantial discipline that they must adopt – according to Deloitte, organizations adopting DevOps see an 18%-21% reduction in time to market. By breaking down the silos between business and IT operations, DevOps can ensure consistent levels of productivity, efficiency and service delivery, all of which hold weight in these times of heightened uncertainty.

    To put it simply, DevOps can help businesses compete in already congested marketplaces. Through a foundation of continuous integration (CI) and continuous delivery (CD), organizations can ensure the customer receives the product they demand in the fastest time possible, while mitigating any elongated frustrations experienced from a lack of harmony between systems engineers and operations teams. Incorporating AI and ML into that DevOps strategy will take things to the next level.

    AI and ML Are the Next Evolutionary Step for DevOps

    Today’s companies are data-driven and being built as digital platforms. However, just 28% of organizations are currently succeeding in their digital transformation journeys. Increasingly, corporations are looking at what AI and ML can do to help them realize their transformative ambitions.

    Both the AI and ML markets are expected to experience huge growth over the next three to four years. Analyst firm IDC, predicts worldwide spending on AI systems will reach a href=”https://www.marketresearchfuture.com/reports/machine-learning-market-2494″>42.8% by 2024.

    What AI and ML reveals for these companies, and the increasing value of what Al, ML and devices can do together, are changing the way organizations view the world as they digitally transform. Coupling AI and ML with DevOps will lead to a significant shift in what DevOps gets involved with. 

    Primarily, it sets DevOps front and center of an organization’s wider digital transformation ambitions. If digital companies run on living data, then the development of these intelligent systems is an enticing environment for DevOps to prove its wider value to the organization like never before.

    Security Takes the Center Stage

    According to a TechTarget survey of key IT decision makers, cybersecurity and risk management were found to be the number one area for spending this year, with more than 53% of respondents saying they saw budgets increase in this area. And security is a crucial element that any organization employing a DevOps strategy should be considering. 

    DevSecOps is the simple premise that everyone involved in the software development cycle is responsible for security. In fact, the saying “security is everyone’s responsibility,” is a mantra that has been repeated often, and just as often ignored. Embedding security within every part of the development process, ensures security and compliance monitoring tools keep pace with the speed and agility that DevOps offers. It is a common understanding that security is the biggest block to the rapid and seamless development and deployment of systems, as security solutions have not traditionally been built to test and code at the speed DevOps requires. 

    Ultimately though, more automation from the start, reducing the need for manual configuration from security architect is where DevSecOps shines. This reduces the chance of misadministration and occurring faults, which can lead to downtime, and potential breaches or attacks. Quite often, the best ways to secure your organization is through simple hygiene factors, such as regular patching and software updates. 

    The reality is that every organization employing DevOps should really be approaching it as DevSecOps. Security is of ever growing importance to each and every organization and, through empowering it with AI and ML processes, it can be enhanced too, simplifying the processing of data to easily identify threats or potential vulnerabilities in the security makeup. 

    Reaching Beyond Human Capability

    The future will be made up of connected intelligent systems that span the intelligent edge, all the way to the cloud. The expectations of these systems are based on the lifecycle of a typical mobile application with constant feature enhancements. But, how do you know what to deliver next, especially when things are moving so quickly, and as developers are inundated with information and data from a number of different sources? This data deluge can be powerful, but it can also be overwhelming.

    Crucially, this is where the power of AI and ML comes into play. AI and ML will aid developers in making sense of the information housed across various data warehouses. In DevSecOps, there has always been an approach to automate everything, and AI and ML will be instrumental in automating the analysis and processing of data – a task that is now far beyond the capabilities of humans.

    Incorporating AI and ML will enable developers to better understand and use the data at hand. This will see developers understand not only the error, or the occurrence of a fault, but the detail of what happened in the run up to the fault – vastly reducing the chances of incurring that fault again. AI and ML will also be responsible for enabling the transformation from diagnostics to prognostics across any and all tools and systems, making it easier for developers to anticipate, identify and resolve faults or errors. 

    Increasingly, we’ll see organizations benefit and drive value from real-time insights. They’ll do this through AI and ML frameworks deployed on active systems to deliver optimizations based on real-time development, validation and operational data. This level of real-time actionable insight bolsters DevSecOps’ ability to achieve CI and CD, through improved, reduced mean time to resolution, easing the impact on operations and, ultimately, enhancing the end-user experience. It remains to be seen if incorporating AI and ML into the DevSecOps cycle will achieve the delivery of self-healing systems that can detect and resolve issues without the need for human intervention. With true AI, however, this might well be possible.

    The benefits and potential use cases of AI and ML are widely acclaimed, and while we are still some way from seeing their full potential, the capabilities they currently possess are revolutionizing many sectors. The fact is, if DevSecOps is to continue to keep pace with the vastly growing digital data economy, then it will become reliant on advanced technologies such as AI and ML. Data is powerful if used correctly, but with so much of it to process and analyze, that can be a challenge.

    A move toward secure automated processes is the progressive step that many organizations need to consider if they are to realize their digital transformation ambitions. Organizations cannot continue to do things the traditional way and expect to get the results that the new world is looking for.

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

  • GitLab Releases Massive Update to CI/CD Platform

    GitLab Releases Massive Update to CI/CD Platform

    GitLab has updated its continuous integration/continuous delivery (CI/CD) platform with a raft of capabilities spanning everything from value stream management to cybersecurity.

    In addition, GitLab announced it is making generally available Gitaly Clusters, which enable DevOps teams to create a warm replica of a Git repository.

    Brendan O’Leary, senior developer evangelist at GitLab, said with release 13 GitLab continues to build on a single code base that allows the platform to be managed and accessed as an integrated set of applications rather than disparate components that DevOps teams need to pull together and then manage.

    In terms of core DevOps capabilities, the latest release adds the ability to customize the Value Stream Analytics module to specific workflows. GitLab is also planning to make it possible to visualize stages of a workflow.

    GitLab is also improving traceability between requirements and has added the ability to visualize the workflow associated with a specific release. A future release will enable DevOps teams to employ feature flags to conduct both A/B testing based as well as create feature flags from merge requests and to filter feature flags by status, according to the company.

    Other capabilities added include more customizable dashboards, with security dashboards now being shareable outside of GitLab to foster collaboration with IT security teams. Future releases will add Kubernetes Clusters to the dashboard to show all clusters and pods in use.

    DevOps teams now can route existing monitoring alerts to GitLab for triage and incident resolution. At the same time, GitLab has moved design management to the core platform.

    GitLab is also now making AutoDevOps, which provides pre-defined CI/CD pipelines, available on Amazon Web Services (AWS).

    In terms of cybersecurity, GitLab has revamped the way the platform manages vulnerabilities to make it easier in a future update to prioritize remediation efforts.

    GitLab also has static application security testing (SAST) support for .NET frameworks and has expanded support for offline environments. There’s also now support for dynamic application security testing (DAST) for REST application programming interfaces (APIs) and access to full commit history scan for secrets. Fuzz testing support will be introduced later this year, according to the company, along with an ability to secure secrets across services. GitLab also plans to add integration with security tools that track container behavior analytics, as well as an out-of-the-box container network policy.

    Thanks to GitLab’s collaboration with Okta, there is now also tighter integration with Okta’s System for Cross-domain Identity Management, which can be provisioned for a GitLab group.

    In terms of compliance, GitLab also plans to enable DevOps teams to establish a compliance framework, adopt its regulatory controls and simplify audit reporting. The company is also working on an initial security policy user interface to simplify setting up security guardrails.

    Finally, GitLab has become a Common Vulnerabilities and Exposures (CVE) ID Numbering Authority (CNA). GitLab users can request a CVE from GitLab, either for GitLab itself or for any project hosted on GitLab.com. In the future, users can request CVE IDs directly from within GitLab.

    O’Leary said GitLab is working toward increasing developer confidence in their security skills. By making it easier to embrace best DevOps practices, developers no longer will have to tiptoe around security issues that they today largely have little to no familiarity with, he said.

    In general, O’Leary said GitLab’s biggest challenge is getting organizations to move beyond simply using it to manage source code. Once organizations do make their first foray beyond source code management, however, it’s not too long before they are employing a wide range of modules, he noted.

    Of course, encouraging organizations to dive deeper DevOps has as much to do with the culture of the organization as it does the capabilities of the CI/CD platform employed.

  • The Best Approach to Help Developers Build Security into the Pipeline

    The Best Approach to Help Developers Build Security into the Pipeline

    Speed and agility are at the core of digital transformation and DevOps culture, and have quickly become a business imperative for organizations that want to remain competitive. Speed cannot come at the sacrifice of security, though. The pace of software development requires that security be baked into the code from the start rather than tacked on after the fact. Developing secure code fast requires empowering developers with the skills and tools they need and building security into the DevOps pipeline.

    Embracing DevSecOps

    DevOps culture and the drive to work faster and more efficiently affects everyone in the organization. When it comes to creating software and applications, though, the responsibility for cranking out code and producing quality code falls on developers.

    The pace of DevOps culture doesn’t allow for anything to be an afterthought. It’s important for developers to support security directly as a function of application development in the first place, and to operationalize security within the continuous integration/continuous deployment (CI/CD) pipeline.

    Unfortunately, traditional education does little to prepare them. It’s possible to get a PhD in computer science and never learn the things you need to know to develop secure code. As organizations embrace DevSecOps and integrate security in the development pipeline, it’s important to ensure developers have the skills necessary. You also need to focus on both the “why” and the “how” in order to build a successful DevSecOps training program.

    Don’t Just Check the Box

    Not all training is created equal. Consider why you’re doing the training and the outcome you hope to achieve rather than doing training for the sake of training. Many organizations focus on training developers in secure coding practices from the perspective of compliance. It’s crucial to engage developers in a meaningful way, though, and not just check a box.

    Many compliance frameworks, such as PCI-DSS, require ongoing application security training, but compliance training often reinforces the wrong lessons. Developers learn the most expedient way to check the box and achieve compliance rather than learning the most efficient way to develop secure code. This approach also causes developers to feel like the security team looks down on them or doesn’t understand the challenges they face or the expectations they have to meet.

    The Carrot and the Stick

    How you do security is also important. Training works better when developers feel like they are part of the process and when they have a reason to want to excel.

    For nearly everyone, doing something in practice reinforces lessons better than just reading content or listening to a webinar or video. Interactive labs are more engaging and provide feedback as developers go through the training. They can practice writing secure code with guided practice that is self-paced. They can also get hands-on experience exploiting vulnerable applications, then patching them back up.

    You should implement developer training that creates incentives for developers by gamifying training. Create custom Capture the Flag events, track individual progress and provide a leaderboard that enables healthy competition among the developers.

    You also want to provide developer training that is relevant to your organization’s preferred coding languages and business objectives. The training should teach skills and strategies that are applicable to the code your developers work with and give them tools they can use immediately to improve the security of the applications they’re working on.

    Speed is essential for businesses to maintain a competitive edge today, and security is more important than ever. Make sure you have the training in place to help shift application security knowledge left and integrate security to mature DevSecOps practices.

  • 5 Ways to Detect Application Security Vulnerabilities Sooner to Reduce Costs and Risk

    5 Ways to Detect Application Security Vulnerabilities Sooner to Reduce Costs and Risk

    Security testing has always been an important step in the application development process. Yet, traditional measures often occur too late in the process to effectively find and fix vulnerabilities before causing costly production delays, or worse, putting organizations at risk for potential security breaches.

    To minimize security-related costs and risks, testing needs to occur sooner and more frequently throughout the development process. But, how can you accomplish this while keeping pace with growing application development demands?

    Looking at automation can help. Development teams have been using automation to streamline manual activities such as build, deployment and functional testing for years now, and it is time security testing joins the mix. By integrating automated security validation into the continuous integration/continuous development (CI/CD) pipeline, you can catch vulnerabilities sooner, reducing the potential risk and financial impact.

    In this article, we’ll look at five ways automated technology tools can help safeguard the CI/CD pipeline: SAST, detecting OSS vulnerabilities, identifying compromising credentials, DAST and verifying cloud infrastructure security.

    Your CI pipeline provides a ready-made check-in point to install the following automated security gates and pinpoint vulnerabilities.

    Static Application Security Testing (SAST)

    SAST provides the earliest check-in opportunity, allowing you to identify potential issues at the coding stage, so you can resolve problems without breaking builds or allowing vulnerabilities to get passed to the final application release.

    Commercial solutions such as Checkmarx help to identify hundreds of security vulnerabilities and weaknesses in custom code. You can also leverage many open source linters for your specific platforms to detect various vulnerability patterns that can compromise code security.

    Detecting Open Source Software Vulnerabilities

    Just because the code is secure doesn’t mean the entire application is protected. Most applications use a large number of dependencies, or third-party open source software (OSS) components. These may have various security vulnerabilities and put your application at risk.

    Tools such as Whitesource Bolt and Black Duck can scan all of your projects, not only to detect OSS components, but also identify and provide fixes for any known vulnerabilities. 

    Identifying Compromising Credentials

    Human error is always a security concern, especially when it comes to credentials. Just consider how many times you’ve heard of developers committing code only to later realize they’d accidentally included a password. These errors can lead to high-cost consequences for organizations.

    There are many tools that scan for secrets and credentials that can be accidentally committed to a source code repository. One example is Microsoft Credential Scanner (CredScan). Perform this scan in the PR/CI build to identify the issue as soon as it happens so they can be changed before this becomes a problem.

    Once an application is deployed, you can continue to scan for vulnerabilities through the following automated continuous delivery pipeline capabilities.

    Dynamic Application Security Testing

    Unlike SAST, which looks for potential security vulnerabilities by examining an application from the inside—at the source code—Dynamic Application Security Testing (DAST) looks at the application while it is running to identify any potential vulnerabilities that a hacker could exploit.

    OWASP Zed Attack Proxy (ZAP) is an open source tool for performing pen testing on web applications and APIs. Pen testing helps ensure that there are no security vulnerabilities hackers can manipulate. It can be installed as a client application or come configured on a docker container. OWASP ZAP scans can be incorporated into your pipeline to check every deployment for security vulnerabilities.

    Verifying Cloud Infrastructure Security

    Finally, in addition to validating the application, the infrastructure should be validated to check for vulnerabilities. When using a public cloud, deploying the application and shared infrastructure is easy, so it’s important to validate that everything has been done securely.

    Each public cloud includes tools to help verify that the infrastructure has been provisioned securely. APIs can be leveraged to check immediately after deployment in lower environments to help ensure any infrastructure security issues are caught before they get to production. Additionally, tools such as InSpec provide compliance-as-code to enforce the intent of provisioned infrastructure is always being met.

    Enabling continuous security validation through the CI/CD pipeline can help fortify applications against an expanding array of security threats that can lead to significantly higher costs and exposure. At the same time, automation tools can provide added layers of protection while meeting the organization application development demands.

  • Cloud-Native Security and Performance: Two Sides of the Same Coin

    Cloud-Native Security and Performance: Two Sides of the Same Coin

    You’re running Kubernetes in a production environment, and you need to apply a patch — perhaps to a commercial application, an open source component or even a container image. How long should it take to implement that patch in production? Thirty days? One day? One hour?

    Remember, cloud-native environments are supposed to respond to change in real-time. Such a response isn’t simply scaling up or down as needed. It’s also essential to respond to security threats, and performance issues, as close to real-time as possible.

    Containers, and the microservices they support, are also ephemeral. They can live for five minutes or even less, and yet unpatched microservices are just as dangerous as more permanent code.

    Patching must also fit within your application lifecycle. Teams with a mature DevOps process typically release code weekly, daily or even hourly. Their ability to apply the patch and roll to production quickly, significantly reduces their security risk. Are your operators up to the task?

    Poor Security Management Becomes a Performance Problem

    The connections between security and performance go well beyond cloud-native environments. Denial-of-service (DoS) attacks obviously target a site’s performance, as do cryptojacking and to a lesser extent, ransomware attacks.

    In many cases, performance monitoring gives an organization its first indication that such an attack is underway. However, monitoring isn’t just for recognizing attacks in progress. It also plays an important role in the prevention of attacks as well — especially in cloud-native environments.

    To understand this point, think about how organizations have traditionally handled patch management, especially to software infrastructure: A vendor (or open source project) releases a patch. The enterprise applies the patch in a test environment that resembles production somewhat. After running a range of integration tests over the course of days or even weeks, the ops team may be ready to deploy the patch into production. 

    Another likely scenario: The ops team may collect several patches to different pieces of software, hoping to test and deploy them all at once. In the meantime, more time goes by, giving attackers even more opportunity for mischief.

    The reason that applying patches in an enterprise production environment takes so long is because IT leadership perceives that patch management is a high-risk activity. Patches may make a piece of software behave poorly or not at all — and the complex interdependencies among both applications and infrastructure components compound the risk of failure unpredictably.

    Cloud-Native Computing Changes the Equation

    Cloud-native computing extends cloud best practices such as scalability and resilience to the entire enterprise IT landscape, providing a new paradigm for computing across hybrid IT environments that leverage virtualization, containers and serverless computing as appropriate.

    At the center of the cloud-native movement is the open source container orchestration platform, Kubernetes. Kubernetes requires and reinforces a cloud-native architectural approach that decomposes applications into containerized microservices. 

    Deploying, managing and operating microservice-based workloads at scale becomes the central challenge for Kubernetes, and for cloud-native infrastructure in general.

    To manage patches, organizations must follow cloud-native principles. Monolithic, “test everything for weeks” approaches simply do not align with the dynamic, ephemeral nature of cloud-native software.

    Just as application developers use canary testing for features they are rolling out, canary testing infrastructure updates largely supplants testing in the full-blown test environment. 

    Testing patches (or updates) become an ongoing, largely automated process of trying new configurations in limited production environments, analyzing the resulting performance and rolling back changes if necessary.

    Operators can now test patches (or new releases) more quickly in production, in a way that ideally minimizes the impact on the applications that end-users interact with.

    How, then, should operators manage such canary environments? By monitoring the performance of the software under test.

    The Convergence of Security and Performance Monitoring

    Unpatched software is the leading source of vulnerabilities in the enterprise IT landscape, and managing patches in dynamic environments requires performance monitoring.

    Add patch management to other performance-related cyberthreats, such as denial of service, ransomware and cryptomining, and it’s clear that security and performance monitoring are two parts of a broad spectrum of IT operations management (ITOM) capabilities.

    In cloud-native infrastructure, ITOM doesn’t stop at monitoring. Instead, operators require observability tools that monitor logs, traces and metrics across the entire infrastructure, in addition to providing tools that operators can use to mitigate and prevent problems with the infrastructure.

    In other words, where monitoring is a passive, “watch the dashboard” activity, observability goes the extra mile, promoting an active, “understand and fix the problem” mentality.

    It doesn’t really matter if those problems are performance or security-related — in many cases, there’s no distinction. Today’s operators must work with tools that bring the two together into a full-fledged security, compliance and monitoring solution.

    The Intellyx Take

    Some analysts argue that IT infrastructure has followed a natural progression from on-premises servers to virtualization to cloud computing to containers. However, there is a fatal flaw in this argument.

    The first three environments in this sequence follow a clear pattern, as virtual machines work much the same as physical servers, be they on-premises or in the cloud. As a result, coding applications remained largely unchanged as enterprises worked their way along this progression to the cloud.

    Containers, however, are fundamentally different — especially once you place them into Kubernetes and the cloud-native context overall. With cloud-native computing, it’s essential to rethink the nature of the application from the ground up. Cloud-native computing is, in fact, an entirely new paradigm for enterprise IT.

    It’s no wonder, therefore, that core operational activities like security and performance monitoring have a new role in the cloud-native world. Indeed, security and performance are every bit as important as before, but today, we must deal with both at once in the context of a dynamic, ephemeral application landscape.

    Only within this context does it become clear what cloud-native vendors like Sysdig are offering. The world of IT infrastructure is changing, and with it the world of enterprise application development and deployment. Security and performance are as important as ever. Don’t let them fall through the cracks.

  • How to Secure the Intangible — Cloud Native Security in the New Age

    How to Secure the Intangible — Cloud Native Security in the New Age

    People don’t want to buy a quarter-inch drill. They want a quarter-inch hole.

    Companies aren’t interested in managing IT; they’re more interested in results. They want to deliver software quickly and focus on their core product or service. This is where the concept of cloud native computing comes in—and why securing it has become critical. 

    Traditionally, companies had many servers and resources. Today we’re moving toward a simpler reality. Developers are focusing on what’s needed to deploy business logic, regardless of what it’s deployed on. That’s why it’s particularly appealing to move to software without the server and the added complex management of IT overhead. 

    If a company can push its offerings without hardware, patch management, storage and so forth, and it can do it more affordably and faster, it’s a great win. 

    The Paradigm Change

    2012 was the golden age of IT, where admins ruled the world and developers got in line. Moving from that era to 2016, we come to the age of the cloud, where developers were kings.

    For many years, the IT department led—and perhaps stifled—innovation within organizations. Developers’ paths for innovation were limited to the area which they had control, i.e., the application layer. Anything beyond that was the IT department’s call. This included hosting, load balancing, database management and whether to adopt virtualization or advanced networking technologies.

    With the emergence of NFV and cloud computing, that changed. There has been a continuous erosion of the abstraction layers that developers were faced with in the past. In 2020, developers are the masters of their own destiny, pushing their organization toward innovation. All of this is possible not only due to virtualization and cloud computing, but also to the relative simplicity of a developer setting up a full application stack on their own laptop.

    In many organizations, the CTO focus has moved from an infrastructure orientation to an application focus. Developers are the new golden children of these organizations. They hold the keys to increasing company profits.

    What Cloud Native Brings to the Table

    There are many numbers being thrown around about the efficiency of cloud native. Whether it’s 300% reduction in deployment time or a mere 30%, the reality is that the time savings are huge. Many developers will never see a traditional data center again in their lives. In fact, new applications are developed as microservices or at the very least as containers, simply because they’re faster.

    There’s no going back. This new approach enables developers to invest in scalable solutions without making companies preallocate unnecessarily large sums of money. Both applications and infrastructure can scale up or down quickly, using the right amount of resources to provide the best service. 

    Businesses that are seasonal or peak-oriented gain a lot from the movement to cloud native architecture. Users also stand to gain from the move, as they receive the best service possible, without downtime. Everyone comes out on top.

    A Look at the Future

    This movement to broader use of cloud native architectures is a trend that will continue to grow over time.

    By 2025, VMs and bare metal will be as anachronistic as mainframe and token ring networks are today. In fact, most medium-to-large organizations already have some kind of a migration project from VMs to containers in progress. Many developers don’t need to spin up VMs anymore, since they can have a whole application stack running on their laptop using containers. When they are done, they simply lift and shift it to staging and production environments.

    In addition, on-premises and cloud environments are becoming a single entity rather than two separate infrastructures. People used to think that the entire data center was going to move to managed clouds for economical reasons. Today, however, most deployments are becoming hybrid. Organizations are opting to keep some of their on-prem systems (mostly legacy applications that cannot be easily moved to the cloud). IT administrators are starting to think about the deployment in the cloud as an extension of the on-prem data center rather than a separate network that needs to be managed.

    This trend will most likely continue, making it all the more important to understand the changing expectations around how to secure the hybrid network environment. The rate of change for cloud native environments is monumentally faster than on-prem, initiating code in milliseconds.

    Most legacy solutions weren’t built to cope with ephemeral networks and compute entities that go up and down within seconds, one million times a day. So, what’s the best way to future-proof risk management in this ever-changing environment? There is no singular answer, but in general prevailing advice suggests you consider the long view, exploring the options best suited for your approach and then look at each through a one, three and five year lens. 

    Cloud Native Security

    When thinking about the future of security, the basics stay the same and the threat modeling concepts stay the same. However, there are a number of security issues to consider, including policies, permissions and authorizations. As networks are converging, the security tools are as well. Looking forward, only solutions that can provide a genuine single pane of glass to control your digital estate will have a real impact on security.

    When looking at solutions to help apply security to cloud native architectures, ask the following questions:

    • Can I improve visibility in my cloud service? Applications may be deployed over multiple cloud instances and on servers in different sites, and even different regions, making it more difficult to define clear security boundaries. The right tool can help you to understand the scope and layout of your cloud resources, particularly if it automatically discovers applications on your cloud deployment and maps the data flows between them, making it easy to understand applications that you have running in the cloud and how they interact with one another.
    • Can I achieve a single view of multiple environments? The tools used to apply security need to adapt to be able to control hybrid networks across on-prem and multicloud organizations. For example, if your architecture requires policies to be deployed to the edge, how is it managing convergence? Numerous network solutions are barely aware of layer 7 process level, let alone containers. 
    • Can I set and maintain policies across these environments? Consider how solutions address network policies and understand potential challenges from both a technical and procedural point of view. Securing application traffic within cloud native architectures or between applications and external networks is a good start, but in the cloud, it’s necessary to implement micro-segmentation so you can define policies at the application level. By defining which applications are allowed to interact and the types of interactions that are permitted at a granular level, it’s possible to provide the level of security necessary for applications operating in the cloud. Look for tools that provide automatic policy recommendations that can be effectively applied on any cloud infrastructure, streamlining your organization’s security policy for deployments.
    • Can I future proof my cloud native security posture? When planning your future roadmap, think about what your network is going to look like. What type of workloads and network constructs are going to be used? Make sure the security vendors you select provide full coverage for your roadmap.

    When implemented correctly, modern micro-segmentation techniques can offer a simple way to secure a cloud native environment, including solving the unique challenges of containers and providing the ability to create dynamic application policies down to process level. Look for tools that provide a single view and foundational visibility, automatically discovering all network flows and dependencies. This allows your business to take advantage of the best of serverless computing without increasing risk or complexity for security.

  • No Excuses: Lock Down RDP

    No Excuses: Lock Down RDP

    We’ve been at the “everyone working remote” thing for months now, and still there are horror stories of people being attacked via Remote Desktop Protocol (RDP). Early on, it was understandable if not acceptable—but we’re not early on any more.

    During the rush of doing whatever it took to help people work from home, exposed RDP was just one of many stories we heard from systems operators, helpdesk and systems admins. Stories of people carrying desktops home, or thinking that tethering to their phone was a “good enough” internet solution predominated. But those issues are clearing up, and they’re specific to a company or a subset of employees. RDP seems to be more persistent.

    According to Shodan (article last updated end of March 2020), RDP use has spiked—and unprotected RDP use has spiked. Security by obscuring (exposing RDP on non-standard ports) has also gone up, and is not effective versus a determined attack. If your goal is to be secure, history has shown very well that obscurity does not at all work.

    Gil Rapaport wrote a great article about this over on our sister site, Security Boulevard. The only thing I would add is to put it on a Virtual  Private Network (VPN) or RD Gateway with 2FA, if you can. Some organizations still don’t have access to VPN services, but if you do, and RDP isn’t running through them, get to cracking.

    Some areas of the world are coming out of lockdown, but the amount of remote work will not drop to the levels it once was. Not soon, probably not ever. The only thing that was holding up remote work for a wide selection of office jobs was the belief that present was better. Some organizations, via forced remote, have learned that the work can indeed be done by people not warming a seat at HQ.

    So don’t put it off. Make certain you are protected. Sleep soundly at night, knowing that the easy vector for attackers right now is protected for your organization. And keep kicking remote rear. Systems are still running, even with the wild changes that came suddenly, and that’s all you–whether your organization recognizes you or not.

  • The Secure Software Development Life Cycle: Syncing Development and Security

    The Secure Software Development Life Cycle: Syncing Development and Security

    Over the last five to 10 years, the nature of software development has shifted dramatically. Whereas large software releases occurred every six to 18 months in the past, current release schedules have become much more frequent. The waterfall model of software development has morphed into what we now know as the DevOps model.

    As a consequence, DevOps has instigated changes in the traditional waterfall security touchpoints. In essence, DevOps has changed the very nature of how application security needs to be implemented. To avoid friction in the development process, application security activities must be adapted to the new world of DevOps practices. It has to go beyond the basics of threat modeling, design review and two weeks of pen testing.

    Under DevOps, some development organizations now do software releases on a daily, weekly or bi-weekly cadence. But they’re still grappling with older application security models. As a result, development and security testing can be out of sync—you cannot conduct a two-week pen test on software that’s released weekly. These organizations need effective security assurance in their SDLC that’s good, quick, early and—above all else—automated.

    The Changing Nature of Software Development

    The way software is developed keeps changing. And it keeps accelerating. Application security needs to change to catch up. Automation will play a key role in enabling application security to maintain the pace of DevOps. DevOps needs automation to effectively deal with software release cadences that occur on a daily, weekly and bi-weekly basis as well as to increase agility generally within the SDLC.

    For example, DevOps accelerates when the automated pipeline embeds application security scanning into pre-commit checks. In this way, consistent levels of application security testing apply every time developers check in code, resulting in a fully automated check-in process. But automation doesn’t lock developers into the same level of security for every code change. For example, if the change only involves altering the color of a logo, heavy security scanning and manual won’t be necessary. At least not the way it would be if the application is accessing sensitive data.

    So, instead of giving developers quarterly SAST results, automation puts the code analysis right there in front of developers as they’re checking in code (via certain IDE plugins). Presenting the code analysis findings to developers, while they are still in the code, has several advantages:

    • The code is still fresh in the developers’ minds.
    • Coding problems can be caught earlier and more easily while developers are still thinking about the code.
    • It mitigates the risk of developers not remembering the code context at a later date.

    Overall, the more automation there is in application security the better it is for open source validation, container scanning containers, QA testing, API security and more.

    Automated Security Assurance and Out-of-Band Activities

    When it comes to implementing testing in DevOps, you must balance automated security assurance with out-of-band activities. That means it’s sometimes appropriate to slow down the automated security process. Even in a completely automated DevOps process you may need to slow down to make necessary changes. It’s true a code change, such as just changing the background color on a web app, may not be too risky. There’s no problem with automating that DevOps step and pushing out the change. But, if your web app interacts with customer data, you’d be prudent to slow down and take the next application security test out of band, and make sure you’ve got the procedure right because it’s much riskier.

    There are different levels of risk and severity within each release of an application. Development organizations need to accept this and adapt to each release’s potential risk and severity level. Then, they need to provide the appropriate level of security assurance and security coverage, whether that is automated within the DevOps workflow, performed out of band or some combination of the two.

    Life in the Fast Lane

    For DevOps organizations, one of two avenues beckons to them: the security express lane or the security slow lane. You could create an automated DevSecOps process across the development organization—the security fast lane. But, there’s no one-size-fits-all DevSecOps process for enterprises. That’s because there could be up to hundreds of development teams within an enterprise. And there’s not always a standardized process that all dev teams can follow. It’s a challenge to adapt automated security to each development team. Those in the security fast lane should use a security champion to work with the development team and be the point person to assist them with understanding application security needs and remediation guidance.

    In the security slow lane, individual development teams may still be enabled to go fast. The difference is that they will pick the SDLC tools that make the most sense for that team. Then, they should also pick the application security tools that make the most sense for them. The bottom line for organizations is that application security needs to involve an acceptable level of friction for developers to make DevSecOps work. If there is too much friction, developers will bypass application security in favor of expediting coding activities.

  • VMware Carbon Black Developer Day 2020: Bringing DevSecOps to the Fore

    VMware Carbon Black Developer Day 2020: Bringing DevSecOps to the Fore

    Developer Day is a VMware Carbon Black’s virtual event that connects intermediate to advanced security developers with Carbon Black experts to learn advanced API and integration techniques. The event takes place Tuesday, May 12, starting at 11 a.m. EST.

    Developer Day, which occurs the day before VMware Carbon Black’s Connect 2020 virtual conference, focuses on automating workflows by integrating the security stack. Attendees will hear from the VMware Carbon Black developer relations team, as well as their partners who have implemented the product APIs.

    Here’s what attendees can expect at this year’s Developer Day:

    • How to build an open source toolkit to enable security operations using Carbon Black’s complete platform API.
    • How to use Red Canary’s suite of tools to enable a variety of security operations.
    • Demos of the latest capabilities.
    • How to get started with Carbon Black Cloud Event Forwarder.
    • Explore the Binary Analysis SDK, the newest addition to the developer toolbox at Carbon Black Cloud.
    • A demo of a bidirectional integration between VMware Carbon Black EDR and Lastline Defender.
    • Discover what’s coming in the Carbon Black Developer Network.

    Participants will have a chance to be entered into a raffle to win Developer Day swag and other prizes. For more information and to register, visit the Developer Day website.

    Hear more about Developer Day as Scott Lundgren, CTO of VMware Carbon Black, discusses what’s in store during the four-hour event with MediaOps Managing Editor Charlene O’Hanlon.