devopsy.kinsta.cloud

Tag: cloud

Best Practices for Cloud Incident Response

Cloud computing is now mainstream, with almost all organizations running at least some resources in the public cloud—whether software-as-a-service (SaaS), platform-as-a-service (PaaS) or infrastructure-as-a-service (IaaS). Security teams have been scrambling to adapt to cloud environments, and with the growing adoption of DevSecOps, they are working together with DevOps teams to secure cloud systems from the ground up.

As your organization discovers the best way to secure its cloud investments, you also need to develop an incident response strategy for the cloud. Even if your cloud security controls are perfect (and they aren’t), attacks will happen. Knowing what to do during an attack and preparing teams for incident response can be the difference between an incident quickly contained and resolved, and a multimillion dollar disaster.

What Is Incident Response?

Incident response enables organizations to make sure they are aware of security incidents and can respond in time to limit the damage to their systems. The objective is to block attacks and prevent similar attacks in the future.

The SANS Institute’s six-step incident response process provides a structured framework for security incidents. These steps are:

Prepare—establish security policies, carry out risk assessments, determine which assets are sensitive and establish an incident response team.
Identify—monitor your systems to detect anomalous activity, identify real security incidents and investigate the severity and type of threats.
Contain—conduct short-term containment procedures to stop the spread of the threat, followed by long-term containment, such as applying temporary fixes and rerunning a clean system.
Eradicate—identify the root cause of the incident, remove malware and implement measures to prevent future attacks.
Recover—restore your production systems and apply measures for preventing further attacks. Test and monitor recovered systems.
Learn—perform retrospective analysis within two weeks of the incident with complete documentation evaluating containment efforts and determine how you can improve the incident response process.

How to Prepare Your Cloud for Incident Response

There are several ways you can prepare your incident response team and your cloud environment for more effective incident response:

Establish response goals—determine incident response objectives in consultation with stakeholders, legal advisors and organizational leaders. Common goals include problem control and mitigation, restoration of affected resources, and storage of data for evidence and attribution.
Use the cloud to respond—ensure your cloud resources include the tools and resources you need to respond to an incident. For example, ensure you have robust cloud-based logging and monitoring systems, and set up cloud-based backup and disaster recovery so you can rapidly restore affected systems.
Determine your requirements—keep copies of logs, snapshots and other evidence in a centralized cloud account. Apply mechanisms to enforce retention policies. Use tags and metadata to maintain visibility and connect logs and cloud resources to organizational units, projects or corporate systems.
Use a redeployment mechanism—if a security anomaly is caused by a misconfiguration, you should be able to remediate it easily by redeploying the resource with the appropriate configuration. Ensure the response mechanisms can be executed multiple times if necessary.
Leverage automation—after identifying recurring problems and incidents, automate as much as possible and break them down programmatically to build response mechanisms for common situations. For example, use the mature auto scaling service on AWS or Microsoft Azure’s infrastructure-as-code (IaC) capabilities. This is much easier on the cloud than it was in an on-premises data center. Ensure you use human response only for unique, new or critical incidents.

Effective Incident Response in the Cloud

Use the following tips to improve your ability to respond to security incidents in a public cloud environment.

Shift Your Focus

Cloud environments require you to monitor different elements than you would in traditional on-premises environments. In the cloud, you should focus on applications, APIs and user roles. Consider how incident responders can operate successfully in a cloud environment, and what tasks they may need to perform. The incident response team must have proper access and visibility into your systems so they can detect, remediate and prevent attacks.

Integrate Alerting and Incident Management Tools

The security team must have direct access to supporting data to triage alerts and classify incidents. To this end, security alerting tools should be integrated with any incident management tools you use, like PagerDuty and Slack, for example. This enables security alerts to directly reach the existing tools and workflows used by your teams. Responders won’t have to alternate between tools to see what is happening.

Build an audit trail to capture the response to each alert, which will provide visibility and accountability and help you refine your response processes. All actions taken in security tools must be visible in the relevant collaboration tool, so you can see who dismissed a specific alert and when, and what annotations they made.

Work with Your Cloud Provider

Cloud providers usually have an incident response team, but you cannot assume the vendor will handle everything during an event. Be aware of the shared responsibility model, where cloud providers are responsible for securing the infrastructure, while the customer is responsible for data and workloads.

Make sure you understand the service agreement for your cloud provider and who is responsible for exactly which element of the response. Find out exactly what alerts you can expect from the vendor’s team and how it can support your own team. Having a clear relationship and establishing points of contact can save critical time during an incident.

Protect Your Logs

The major cloud vendors provide logging capabilities for their environments, including log files or operational metrics to provide insight into service operations. Logging services may be free or paid, ranging from basic access logs to complete audit and configuration logs. Most cloud logging service will allow you to store logs outside the cloud or on-premises—and it is critical to do so.

Logs are a useful resource for incident response investigation, and you must ensure they remain inaccessible to attackers. An attacker might be able to compromise your cloud system or services, but they won’t be able to modify or delete your logs. Logs are a protected source of information that can help you identify the attack timeline, targeted systems and the attacker’s IP address. This provides a reliable starting point for investigations.

Conduct Cyber Range Training

Organizations often rely on exercises to train or test their security and incident response capabilities. Today, cloud environments provide an opportunity to simulate your production network in a protected environment, allowing your security team to practice their response to real attacks on your network within a safe setting.

Tools such as AWS CloudFormation allow you to quickly design and deploy training networks that are identical to your actual network. You can keep costs down by limiting the duration of exercises. These exercises may be the best way to prepare your team to respond to attacks in the real world.

These are the basics of security incident response, preparing a cloud environment for incident response and how teams can effectively react when the inevitable attack occurs. In short, it’s important to:

Focus on what matters – In the cloud, this is APIs, applications, and identity and access management (IAM) systems.
Integrate alerting and incident management tools – The cloud provides ample automation capabilities. Use them to respond automatically to common anomalies.
Work with your cloud provider – You are not alone in the cloud, and teams need to understand exactly which part cloud providers will take in responding to an incident.
Protect your logs – If logs are exposed to tampering, you will have no way to detect, investigate and respond to attacks. Protect them at all costs.
Conduct cyber range training – You’ll never really know what it’s like to respond to an incident until one actually happens. Instead of waiting for a real attack, conduct a “cyber range training” or security drill and see how everyone works together in an attack scenario.

Now, you’ll be better prepared as you move towards a cohesive cloud security strategy for developers, operations, and security teams.

June 29, 2021
How Containers Simplify DevOps Workflows and CI/CD Pipelines

DevOps enables organizations to capitalize on the flexibility of cloud resources in real-time, which is a huge game changer. Just as the adoption of Agile methodology can make a development team more responsive, DevOps revolutionizes implementation of IT objectives from end to end, from a waterfall-style process gating company productivity to a dynamic process that makes better-quality software fast and easy.

Organizations have been taking advantage of increasingly flexible resources and moving away from conveyor belt-style project delivery with hardware and software resource planning, ordering and integration. DevOps provides a way to address the question, “If we can provision resources quickly and easily, how can we complete entire projects with similar responsiveness?”

As DevOps lowers the wall between development and operations, staying sane and accountable doesn’t have to bog down processes. Structured communication still takes place, but in an iterative, incremental fashion, much like polishing a jewel.

Instead of lofty goals set in the somewhat-distant future, practical solutions can be created, deployed and adjusted. The process gets applications in the hands of end users far sooner, smooths any rough edges using actual user feedback, and helps organizations not only become more responsive to changing needs but make much more efficient use of valuable software development and operations resources.

Why Dev and Ops Teams Need to Collaborate

It can be hard for an organization’s culture to adapt to this level of change. But both development and operations teams have some pain points that help motivate them to work together more dynamically.

The development (Dev) side of the house wants to deliver more timely solutions, ensure greater acceptance of new applications and use its resources more efficiently. Operations (Ops) has challenges with hardware resource planning; they have maintenance and cost-reduction projects that are delayed. Ops also has insights into new features, efficiencies and integrations, but with no way to implement them.

These and other pain points arise when traditional, waterfall-style processes constrain communication and implementation. Creating a new flow between the two teams helps to reduce these pain points.

Rather than being tied to a specific technology, DevOps is a methodology aimed at making software development efficient. Containerization narrows the gap between development and IT Ops to a minimum. Containers are a great tool for enabling DevOps workflows and simplifying the development and delivery pipelines. Containers hold the code and dependencies required to run an application and reside in isolation. This enables teams to develop, test and deploy apps inside these closed environments. And this doesn’t affect different parts of the delivery, making the lives of testers and developers a lot easier.

Enabling CI/CD

DevOps has created a way to automate processes to build, test and code faster and more reliably. Continuous integration/continuous delivery (CI/CD) isn’t a novel concept, but tools like Jenkins have done much to define what a CI/CD pipeline should look like. While DevOps represents a cultural change in the organization, CI/CD is the core engine that drives the success of DevOps.

With CI, teams must implement smaller changes more often, but they check the code with the version control repositories. Therefore, there is a lot more consistency in the building, packing and testing of apps, leading to better collaboration and software quality. CD begins where CI ends. Since teams work on several environments (prod, dev, test, etc.), the role of CD is to automate code deployment to these environments and execute service calls to databases and servers.

The CI/CD concept isn’t entirely new, but it’s only now that we have the right tools to fully reap the benefits of CI/CD. Containers make it extremely easy to implement a CI/CD pipeline and enable a much more collaborative culture. Containers are very lightweight and can scale endlessly, run on any environment and are very flexible. It doesn’t get easier than this.

Now, you can move code across containers–or container clusters, as is the case with Kubernetes–instead of moving code among various virtual machines (VMs) in different environments. VMs are static and leverage a monolithic application architecture, whereas containers use a distributed microservices model. This opens doors to new benefits when it comes to elasticity, high availability and resource use.

As part of a DevOps team-oriented approach, team members can reach out to their peers and share innovation, feeding their knowledge and experiences into the evolving process. Development teams can put the new resources to use, taking advantages of technologies such as containers and Kubernetes to architect solutions. Working together, this cooperation lets Ops run with the solution, scale it, distribute and upgrade efficiently without delay.

Putting it All Together

DevOps has helped organizations reimagine their entire development lifecycle. And while DevOps brings cultural change, CI/CD is the core engine that makes DevOps successful. New tools like containers now make it easier for organizations to make the most of CI/CD. However, data storage must be taken into consideration, because it undergirds a dynamic DevOps environment. It also provides failover, disaster recovery and other essential availability and reliability features. Software-defined storage offers the flexibility that a dynamic DevOps environment needs. It’s a crucial element in the success of your DevOps program.

June 22, 2021
Automatic Right-Sizing is Magical Thinking
Some months ago, AWS evangelist Corey Quinn wrote a short blog post titled “Right Sizing Your Instances Is Nonsense.” As usual, Corey was spot-on in his takedown of cost-reduction-magic-AI industry hype. But his piece only scratches the surface. I would take the argument a step farther and say that anyone who tells you they can automatically and generally “right-size” compute instances simply doesn’t understand how software works.

Does that strike you as overly aggressive? Stay with me. Even if you don’t wind up agreeing, there’s a lot to be learned about AIOps from a discussion of “automatic instance right-sizing.”

What is Right-Sizing?

Quoting directly from the website of one of the many services that claim to provide “right-sizing” for cloud instances:

“The Recommendations Engine leverages the time series data of relevant utilization metrics for your resources, then creates a statistical model around average and peak utilization periods. The tool leverages historical utilization data to identify performance characteristics across instance types, families and zones to provide valid recommendations for your workload.”

The idea behind this “right-sizing” is quite simple, really: track a bunch of cloud service metrics (and maybe a bunch of OS metrics, too, if they are available), use some statistical model—commonly called “AI” on VC decks—and magically deliver recommendations for a more cost-effective cloud instance type.

There’s just one problem: creating a useful statistical model from generic metrics is practically impossible unless your software is purpose-built to support it, and that is never a software design goal. In fact, software is almost always built in a way that is completely contrary to this goal, and for very good reasons. To understand why, let’s go over the assumptions behind “right-sizing”:
1. The software will be able to use all given resources
2. Performance will improve (or degrade) predictably and uniformly with added resources
3. Metrics accurately describe application load
4. Scaling dimensions are independent
5. There will be no side effects on connected systems
It turns out, none of these assumptions behind right-sizing are generally true.

A Crash Course in Software Scaling

In theory, software is bottlenecked on resources, be they CPU, disk, RAM, network, what have you. In practice, however, it is extremely difficult to build software that can fully utilize resources.

The general curve that describes how software scales with resources or load is known as the Universal Scalability Law (USL). In a nutshell, it says that on any chart showing scale versus performance, you will see a region of linear scaling where adding resources (say, CPU cores) proportionally increases performance; however, you will then see where performance continues to increase on a nonlinear basis, with smaller and smaller gains with every additional resource until, at some point, the benefit is so marginal as to be completely negligible. This is known as Amdahl’s law, which states that the performance of every program is limited by the serial part.

Beyond Amdahl lies the issue of retrograde scaling, the existence of which people often forget about until the consequences hit them smack in the face. In this issue, adding resources actually slows down the system. That’s right. From this point onward, larger servers will make your software slower.

The reason this happens is that, to scale linearly, the workload and resources must be completely isolated and decoupled from each other, which isn’t realistically possible. There are always shared components, e.g. the kernel scheduler, the memory controller, the main PCI bus, perhaps the algorithm requires locking. In any case, the net result is queueing on the shared resource, which might also become a bottleneck when overloaded. Think of a supermarket checkout: you can admit more and more shoppers into the store, but they will still end up waiting at the checkout, eventually, no matter how many registers you open and staff. Performance is limited by the number of checkout counters, not by the number of shoppers or clerks. Worse yet, if the queue gets out of control (maybe people got tired of waiting and shopping carts are literally abandoned in front of remaining shoppers, blocking the path to checkout — think of this as the contention of retries and timeouts), the throughput of checkout will decrease as counters are starved for shoppers.

The USL shows us what happens to throughput as we scale, but what about latency?

As resource utilization approaches 100%, the wait time for the resource will approach infinity in a nonlinear fashion. This is why systems are designed to run at low utilization, so that quality of service does not degrade too much. You might see a server running at 50% utilization and think, “We can use a server with half the resources and save money!” but if you actually try to do that, you will degrade latency and quality of service to an unacceptable level, most likely causing an outage.

The Dark Arts of Configuration

Even if your software is able to take advantage of available resources in theory, it needs to be properly configured to use them. Buffer sizes, thread pool sizes, memory heap size, number of connections—most software has numerous options to tune it for resources and specific workload. You can’t just change the box size and expect it to work! Not to mention, it’s quite possible your current configuration is far from optimal. I’ve substantially reduced cluster sizes on several occasions by making a one-line configuration change.

For example, a common web server configuration is the number of concurrent requests the server can handle (often expressed as number of threads), which relates to the number of CPU cores available, the amount of memory available to the specific workload and the average time it takes to handle a request. The problem you are solving isn’t “What instance size will have the best ROI?” but rather “What combination of instance size and configuration will have the best ROI?” That is a totally different question that requires specific knowledge of the application to answer.

Let Them Eat Cache

In the old days, when you tried to allocate memory beyond what was currently available, the operating system would simply refuse your request. Ah, the good old days were simple! Alas, in our quest to simplify programming and resource management, and to allow software to efficiently adapt to a changing environment, we made common use of resource tradeoffs. For example, a complicated computation can be calculated again and again using the CPU, or the results can be saved and reused, saving CPU time and trading it for the use of RAM or disk. This pattern is quite common; when you overallocate memory, the operating system may trade off CPU to free memory by compressing memory objects, or it may trade off disk space by paging out RAM to swap. Java, Node.js and Go each have a similar tradeoff where they spend CPU time on garbage collecting to free RAM. Modern software makes numerous tradeoffs between CPU, RAM, disk and network in multiple dimensions. The end result is that different resources are coupled in many unexpected and obscure ways.

Lies, Damned Lies! (And Metrics)

Speaking of that server running at 50% CPU utilization, it is quite possible that server is also maxed out on CPU at the same time. How can this be? It’s because the metrics you see are not raw data but aggregates—in many cases, averages—and aggregates hide certain behaviors that can be very important; for example, peaks and bursts, such as the ones you get from compaction, garbage collection and other periodic processes that routinely run in modern software. There are billions of events happening every second on a modern server, and only a few data points of metrics emitted every minute. All metrics are loss-y; it’s simple math, really. But machine learning (ML) models are only as good as the data they work on, so if the metrics weren’t specifically created to show the relevant behaviors—and they weren’t—the model would be completely blind to their existence.

What is “Performance,” Exactly?

Whenever we deal with resource allocation, we are interested in its impact on performance, which raises the obvious yet rather uncomfortable question: what’s your definition of “performance?” Is it throughput? Latency? Mean or the 99th percentile? Of which transaction? Or, perhaps you are mostly interested in the rate of purchases executed on the website? These are all different things, and often, optimizing one might degrade the others.

This kind of discussion is the first step in any performance engineering session—but completely absent from the scope of “right-sizing” services, and the last thing you want is the generic cost function of the ML model costing you money.

This wouldn’t be so bad if all performance goals could be achieved at once, but, sadly, some of them are in opposition: e.g., higher throughput causes higher latency due to queueing effects. When making changes to software systems, we have to know what performance metrics are important to us.

The Curse of Local Optimization

It is very tempting to look at a cluster of machines as an independent system. But if that system is doing something meaningful, it is part of some bigger system, and changing the configuration will likely have an effect on the larger system it is a part of. When we make changes to subsystems, it is with the intent of improving the system as a whole, to make the customer happy and make more money. But when a change to a subsystem is motivated by a desire to reduce the cost of the subsystem, the result is often an increase in the overall cost of the system! This is because the local cost of subsystems is relatively small compared to the cost of the entire system, not to mention the possible reduction in the income of the system. For example, you could save lots of money by using older, slower servers, but your customers won’t be very happy with a slow application and your profits will suffer—which will probably cost you much more than whatever you saved.

To take this ad absurdum, you could save 100% of the subsystem cost by turning it off completely. Of course, the assumption is that changing server sizes will not have any side effects, which, as discussed, is highly unlikely. There will be side effects on connected systems as well, some of which will not appear immediately. Load is variant, and operational overprovisioning and buffers were often put in place for a reason. It’s quite likely the reason for low utilization is safety margins.

The Problem With “Right-Sizing”

The basic problem with “right-sizing” is the rather obvious, yet implicit, assumption that there is such a thing as “the right” size. Software engineering is all about tradeoffs, precisely because it’s very rare (if it happens at all) that one thing can be improved without making another thing worse. Tradeoffs mean business decisions to make, and you really don’t want a generic ML heuristic to make those for you. ML is very good at dealing with problems where a lot of data is available, the data is high quality, the data is predictive of behaviors (which isn’t the case for complex systems!) and most important, the problem is well defined. Most problems in AIOps are very far from this. Don’t take it from me, take it from the people who excel at both high-scale ops and ML.

Even if it was feasible to make such ML models work, software is unable to automatically adapt to different machine sizes and fully utilize server resources. If it were, companies like ScyllaDB and Azul Systems wouldn’t need to exist. Creating software that is scalable and resource-efficient on modern hardware is a very difficult problem, and without those building blocks, ML models are constructing very shaky structures.

It’s worth emphasizing that I’m not arguing against adapting the size and configuration of servers, only that doing so automatically and blindly for some local “cost-saving” goal isn’t the solution you might think. The goal of such changes should be to raise the overall quality and performance of the larger system guided by a theory of how that system works. ML is not a replacement for human thought and learning. There might certainly be an “optimal” instance type, or even a few, but “optimal” implies a target metric that certainly isn’t cost reduction. No system exists for the sole purpose of being inexpensive. All systems exist to serve business requirements first, and to be low-cost second.
June 21, 2021
There’s No Innovation Without Automation

Companies of all sizes and across virtually every industry today have ready access to hyperscale compute, storage and myriad other technologies — without needing the significant budget or technical expertise of a hyperscale cloud provider like AWS.

This is a boon for innovation. Cloud opened the door to cost optimizations, previously out-of-reach cloud-native tools, security improvements and other tangible business benefits. This also created something of a myth in the industry: people commonly think of cloud as “easy.” Yes, migrating existing applications to the cloud can create significant business value. But saying “cloud is easy” can be dangerously misleading.

There are reasons for this perception. A developer with a credit card can create an account and spin up a new environment in a matter of minutes, for example. That’s a far cry from the days when that same IT professional might need to submit a ticket to an internal Ops team days (or weeks) in advance to provision a new Dev environment.

Operating in the cloud at any kind of enterprise scale is not necessarily easy, however. In fact, cloud can be much more complicated than on-premises infrastructure. Consider the sheer number of new tools and services a platform like AWS rolls out in a given month—keeping up with the pace of change and innovation can itself seem like a full-time job.

Complexity becomes an even bigger issue when teams migrate to cloud (or begin pursuing greenfield cloud-native projects) while simultaneously trying to move with greater speed and agility, often driven by a new or ongoing digital transformation project in the company. Think about a team that’s undergoing a shift toward DevOps while also migrating a major legacy system to a cloud—that’s a lot to tackle at once.

Fortunately, cloud complexity is an eminently addressable challenge — so long as you embrace automation. Automation, including the use of embedded or native tools from the hyperscalers themselves, is absolutely critical to cloud success.

Automation is what enables today’s IT teams to achieve the benefits of a cloud migration without saddling themselves with an untenable operational burden. Furthermore, automation is what makes a lot of popular mantras in business and IT today — such as “fail fast” and similar ideas — actually possible.

Automation is the foundation of innovation. There is no such thing as meaningful innovation without automation. That’s because sticking with largely manual operations turns IT into a bottleneck. Technology hampers the overall business rather than drive its most pressing strategic priorities. Organizations that don’t adapt to this reality face big headwinds. Cloud on its own does not solve the problem; cloud paired with automation is what is needed.

Consider the various operational requirements of any IT environment: provisioning, configuration, security, scaling, resource management and optimization, and change control/change management. Without effective automation, each of these alone can require an intensive amount of manual effort to manage in the cloud and quickly become more complicated than their counterpart in a plain-vanilla on-premises environment. If you can’t quickly scale up as your application needs change, whether due to a demand surge or other factors, then you’re not achieving the speed and agility that cloud promises, for example. Likewise, if you can’t scale down machines that are no longer needed, you’re almost certainly wasting money on idle resources. This is where a cloud platform’s autoscaling capabilities come into play.

Similarly, consider your organization’s existing change control or change management processes. It’s a necessary function of many enterprises, especially those who must manage regulatory compliance. When applied manually in the cloud, it can quickly become a byzantine effort that severely limits agility. That’s a nonstarter for most modern businesses. This is another challenge that can be addressed with automation in the cloud.

It’s also important to understand that automation drives quality as much as it drives agility. It enables you to deliver new products and services faster and more frequently while fostering top-notch user experiences. The autoscaling scenario above can reduce capacity-related outages that damage customer experience and the bottom line, for instance. In this way, automation and cloud together form the basis for true operational excellence and its hallmark characteristics of capacity, elasticity, performance, and security.

This is not just the purview of customer-facing applications, either. Competitive businesses must bring the same philosophy to their whole IT portfolio. Innovation depends on internal systems becoming as nimble as a web front-end.

Think about an ERP system like SAP; change on SAP for enterprises has traditionally moved at the speed of an elephant when today’s businesses operate at the speed of a gazelle. You must apply the processes, tools and culture of cloud and automation to back-end systems, too. You can automate operational tasks in the cloud, such as system refresh and other system-level operations. This paves the way to zero-downtime maintenance, patching the database at the OS level while getting rid of the hours of downtime that task would previously have required. Or think of the necessity of backup-and-restore: Via cloud-based automation, you can deliver point-and-click restores that greatly reduce time to recovery.

Again, this is about quality just as much as agility. Applying automation appropriately to a cloud-based ERP system can reduce or eliminate human error, too, further boosting system performance and reliability.

In short, cloud offers great opportunities for enterprises to access transformational innovation. However, you can’t be innovative without being agile, and you can’t be agile without automation.

June 15, 2021
Designing Cost-Efficient Cloud Environments
Today, the days of on-premises data centers are mostly behind us, and the cloud has largely taken over with the promise of scalability, flexibility and cost-efficiency. Despite these promises, the cloud often falls short of these ideals. Why?

Because managing the cloud is hard—especially when it comes to managing its costs. There are no automatic savings the moment you sign up with AWS or any other cloud provider. Instead, realizing cloud savings requires lots of capacity planning, careful analysis, consistent monitoring, accurate forecasting and endless adjustments—it’s enough work to make anyone’s head spin.

But the rewards make it worth the effort. If you manage your cloud correctly, it offers tremendous savings compared to on-premises environments. However, moving to the cloud without first putting a cost strategy in place can cost your organization millions as you scale in the long term.

So, what guidelines should you follow to ensure you’re maximizing your potential cloud savings? Here are some common do’s and don’ts you can start implementing—or stop doing—now.

Moving to the Cloud

Migrating to the cloud is the first, and the most complex step. So before you get started, bear in mind the following:

Do: Analyze Your Environment Prior to Migration

Let’s face it—if you have a disorganized and over-provisioned on-premises environment, you’ll have a disorganized and over-provisioned cloud environment. Unless, of course, you clean it up prior to the big move.

On the bright side, cleaning up your current, familiar environment is less daunting than doing the clean-up once you move to the new and unfamiliar cloud environment. Therefore, it’s critical to analyze your current environment prior to your cloud migration.

Start by decommissioning all assets that are not currently being used. For example, you may have a virtual machine (VM) that was provisioned for a particular project and not turned off once that project was finished. As a result, you’d have an application running that is no longer needed. Identifying and removing these resources now will lower your future cloud costs while relieving engineers of future headaches.

Do: Create a Blueprint for Your Cloud Architecture

Next, you need to re-architect your application stack. Don’t worry, this task isn’t as scary as it sounds. You’ll need to create a list of the infrastructure you’re using now and find its corresponding infrastructure in the cloud. Say, for example, you’re using multiple dedicated servers for message queuing. If you’re moving to AWS, you’ll need to identify similar instance types in AWS prior to your cloud migration.

Don’t: Follow the “Lift and Shift” Approach

It may be tempting, but whatever you do, avoid the “lift and shift” approach. There are certainly ways to optimize your current environment, so simply moving exactly what you have into the cloud is a missed opportunity to reorganize, restructure and optimize performance and costs.

For example, you may be running VMs that are not being used, backing up unused development servers, or storing data that can be allocated to a low-cost archival storage class. Make sure to readjust your architecture to fit the cloud, not the other way around.

Governance

The bottom line is, somebody needs to be responsible for managing cloud costs. Depending on your company size, it can be a team or an individual, but it must get done sooner rather than later.

Do: Ensure Cloud Spend is Managed by a Specific Individual or Team

Sticking to a cloud budget is easier said than done, but if you delegate this task to a team or specific individual, it will be their top priority to ensure your company stays on target. They will be responsible for handling cloud budgets, establishing who can and cannot provision resources and monitoring use.

If you fail to establish governance, you run the risk of having many individuals provisioning resources without any liability or accountability, which results in significant overspend and lots of chaos.

Don’t: Presume Governance Is Only for Large Organizations

Think your company’s too small for governance? Think again.

At least one individual should always be responsible for monitoring your cloud spend and ensuring it stays in line with the allocated budget. This person will work hand-in-hand with finance to create budgets, monitor use, create billing alerts and more.

Cloud Security

If you’re migrating to the cloud without thinking about security, you’re making a huge mistake. It is estimated that cybercrime will cost the world over $10.5 trillion by 2025. Even worse, according to Verizon’s recent study, cloud security breaches have surpassed their on-premises counterparts for the first time ever.

So, needless to say, security should be prioritized when moving to the cloud. Here are some tips to get started.

Do: Develop a Layered, Multi-Tiered Cloud Security Plan

Your cloud security strategy should safeguard both your data and IT assets in the event of a cyberattack, while being compliant with the standards and regulations specific to your industry.

Some cloud security strategies include:
- Building your solution with a well-architected framework
- Using solutions like threat detection, automated patching or security auditing
- Connecting your on-premises network to the cloud using a transit gateway or similar technologies
- Creating enough firewall rules for traditional systems and web applications
Don’t: Rely Exclusively on Your Cloud Provider’s Security Controls

While many cloud providers offer great security solutions, relying on them exclusively will not help you cover your bases. AWS regularly refers to the shared responsibility model, which states that AWS covers infrastructure, but the user must secure their own applications.

Scheduling Your instances

The longer you run your servers, the larger your bill will be. And, unfortunately for us, creating a new VM in the cloud has become so easy that many forget to turn them off when they are no longer in use. This results in cloud costs that are up to 66% higher than they need to be.

So, if you’re looking to cut cloud costs, keep the following in mind when scheduling your instances:

Do: Automatically Schedule Instances

Let’s face it, it’s easy to forget about shutting down instances after hours. In fact, it’s so easy, it can happen to even the best of us. Automatically scheduling instances, on the other hand, avoids human error while simplifying the shutdown process.

AWS’s Amazon Instance Scheduler or Azure’s Start/Stop feature makes it easy to shut down instances from non-production environments during “off hours” and spin them back up once they’re needed. In addition to these tools, you should consider implementing alerting so you can be notified if anything goes wrong in the scheduling process.

Do: Take Advantage of AWS Auto-Scaling

AWS auto scaling enables you to take full advantage of the cloud’s elasticity. The technology continuously monitors your application’s capacity needs and automatically adjusts resources to fit its current use. As a result, you don’t have to spin out a large VM for your workload. Instead, you can begin with a low-spec server and add it to an auto scaling group. When demand increases, more nodes will be added to your fleet to accommodate scale. Likewise, when the demand decreases, the extra nodes will be spun down.

This helps optimize both performance and costs so you’re never paying for resources you’re not using and you always have the right number of instances to run your applications.

Don’t: Allow Your VMs to Run Continuously

This may seem obvious, but as we mentioned earlier, many forget to shut down VMs when they are not needed. For example, 9 AM to 5 PM on weekdays may be your peak hours. This means you probably won’t need certain VMs to run on Saturdays or at 3 AM—so why pay for them? Instead, shut down VMs during “off hours” to ensure your savings are maximized.

Tagging Your Assets

There’s no getting around it—tagging assets is an essential part of understanding your usage patterns and optimizing cloud costs. Asset tags are metadata labels which can be attributed to individual resources in your cloud fleet to track which application it belongs to. Usually, you can assign up to 50 tags per resource, and they can be organized and named according to your needs.

When tagging assets, make sure to keep in mind the following:

Do: Implement a Tagging Strategy Early in your Cloud Journey

It’s never too early to start tagging assets. In fact, the longer you postpone it, the harder it will become. Once your spend and usage increases, which it inevitably will, you will need to have a tagging system in place in order to determine which team is responsible for each asset (so you can have them evaluate resources and costs), deactivate unneeded resources and more.

Tags are extremely useful in many real-world scenarios. For example, if you’re not using a specific application, you can search for the tag “application” with a value of the application’s name. You will then see all resources related to that application, so you can easily delete them.

Additionally, tags can be used to enforce budgets and prevent overspending. Simply set a budget threshold on your tag and set up alerts to notify you when you’re getting close to that threshold.

Don’t: Embark on Cloud Migration Before Tagging Assets

Tagging is simple if you do it in the beginning when your environment isn’t so complex. But it’s excruciatingly difficult once your environment is more mature. So, if you’re moving to the cloud, make sure to start tagging beforehand so you don’t have any regrets.

Do: Use Reserved Instances and Savings Plans

If you’re on AWS, using reserved instances (RIs) and savings plans can save you up to 72% over the cloud giant’s on-demand pricing. The catch is you have to commit to purchasing RIs one to three years in advance, which means you’ll need to predict your usage needs ahead of time. Despite this challenge, RIs offer tremendous savings for those that use them wisely.

Don’t: Purchase Reserved Instances or Savings Plans Without Building a Strategy

When using RIs, it’s crucial to develop a strategy to ensure your savings are maximized. Often, people make the mistake of purchasing many RIs, which are not used. This results in upfront savings, but no return. Make sure to come up with a plan for how you handle reserved capacity. Selling them on the AWS marketplace is a good place to start.

We move to the cloud for the promise of more flexibility and lower costs. But to actualize that promise, we can’t expect the cloud or our cloud provider to do all of the work for us. Unfortunately, cloud savings are not automatic.

That’s why creating a strategy that covers costs, security, and other critical aspects of cloud migration should be your No. 1 priority. Even if you’ve been using the cloud for years, you should continue to reassess your cloud cost strategy to ensure it is optimized fully. Start by pinpointing practices that result in cloud waste and creating a game plan to prevent it from happening.

Keep in mind that new technologies are always emerging, so make sure you are aware of any industry changes which could impact your cloud cost strategy.
June 14, 2021
Majority of Orgs Lack Visibility Into Container Vulnerabilities

Today’s blend of third-party application dependencies and polyglot software development often makes assessing risk difficult. With many new cloud-native deployment models, it can be tricky to discover potential vulnerabilities. These threats take the form of insecure default settings in Kubernetes, over-permissive states, CVEs that threaten container integrity, and other vulnerable conditions.

Plugging gaps throughout the cloud-native strata is now crucial to avoid exposing data and breaking privacy regulations. Yet, gaining visibility into these holdings is challenging, and traditional application security practices may not cut it within a cloud-native context.

A new 2021 CISO Report released by Dynatrace, “Precise, automatic risk and impact assessment is key for DevSecOps,” demonstrates increased false positives and a general lack of real-time container runtime vulnerability scanning among enterprise IT departments worldwide. Of the 700 CISOs surveyed, most report that microservices, containers and Kubernetes have caused security blind spots across their organizations.

Below, we’ll cover the major takeaways from the study to see why new cloud-native development models are leaving security gaps. We’ll consider how CISOs can increase security throughout the cloud-native IT stack while still reaping the rewards of container-based delivery models.

Cloud-Native Security Blindspots

Adopting new container-based technologies may introduce multiple nuanced security implications. Of the tech leaders surveyed, 89% report that microservices, containers and Kubernetes have created new vulnerabilities within their organizations.

Engineers are shipping code to maintain release velocity and to meet the demand for digital innovation. In the process, 28% of CISOs say application teams sometimes bypass vulnerability scans to speed up software delivery. Due to these realities, it’s no surprise that 71% of CISOs admit they are not fully confident code is free of vulnerabilities before going live in production.

As some teams bypass security pre-production, it follows that more aren’t applying holistic security scanning during production. As a result, nearly all organizations (97%) lack real-time visibility into runtime vulnerabilities, found the report.

Adding to the number of cloud-native blindspots is information overload. The report calculated that, on average, an organization receives a staggering 2,169 new alerts of potential application security vulnerabilities each month. Out of this high volume of alerts, 77% of CISOs say they are mostly false positives and not actual exposures.

Due to minimal testing and a high number of false positives, organizations are likely to leave many vulnerabilities unpatched. To make matters worse, developers, pressed for time, may lack the bandwidth to resolve known issues.

Faster Delivery, Harder Detection

Much of the setbacks in vulnerability detection may lie in a general shift toward new ways of working and faster delivery cycles. For example, 63% of CISOs reported that DevOps and agile methodologies are making it harder to detect and manage vulnerabilities.

In addition, 74% of CISOs say traditional security controls such as vulnerability scanners no longer fit today’s cloud-native world, and 77% of CISOs agree that automation could help. This could involve replacing manual deployment, configuration and management with more automated approaches. Others agree that security-as-code is required to ensure high container security best practices.

Another result of more frequent delivery is increased over-reporting. Of the total security vulnerability alerts received per month, CISOs report that only 42% of these alerts require action. More rapid release cycles could thus exacerbate already crowded vulnerability detection systems.

Who Owns Vulnerability Management?

Only 3% of organizations have real-time visibility into runtime vulnerabilities in containerized production environments, the study found. In reality, vulnerability scanning in production is only happening once a month or less within 68% of organizations.

To compensate for this gap, most CISOs believe the onus is not on the security team but the application and DevOps teams to manage and respond to vulnerabilities—85% of CISOs believe these groups should hold responsibility for vulnerability management. These findings come to light as other stakeholders advocate for increased full-cycle developer control and encourage the DevOps mindset across roles.

Handing more control to developers sounds good, yet, 64% of respondents say developers don’t always have time to resolve vulnerabilities before code goes into production. As a result, over one-quarter of application teams bypass vulnerability scanning entirely. Often, engineering teams may not frequently sync with security groups, and DevSecOps principles are not yet pervasive throughout all organizations.

The report also highlighted the fact that existing security tools are often ineffective; 69% of CISOs say security tools slow down DevOps because they only focus on one state of the software delivery cycle.

Cloud Use Requires Security Repositioning

As cloud architectures rise in prominence, organizations are adopting cloud-native tools like microservices, containers and Kubernetes. There is also the chance of multi-tool conditions further complicating the vulnerability scanning process. With more systems to protect than ever before, teams may have to reposition their approach to vulnerability detection.

“The increased use of cloud-native architectures has fundamentally broken traditional approaches to application security,” said Bernd Greifeneder, founder and chief technology officer at Dynatrace. “This research confirms what we’ve long anticipated: manual vulnerability scans and impact assessments are no longer able to keep up with the pace of change in today’s dynamic cloud environments and rapid innovation cycles.”

The Global CISO report, “Precise, automatic risk and impact assessment is key for DevSecOps,” from Dynatrace, queried 700 chief information security officers (CISOs) on their monitoring practices concerning vulnerabilities. To review the report’s full findings, you can download it here.

June 14, 2021
How to Move Fast Without Breaking Security

“Move fast and break things,” is a familiar motto. The phrase, attributed to Facebook CEO Mark Zuckerberg, helps to explain the company’s stellar growth over the past decade, driven by its product innovations. However, while it’s a useful philosophy for software development, moving faster than you’d planned is a risky approach in other areas, as organizations globally realized during the COVID-19 pandemic. While 2020 saw digital transformation program timelines advance by up to seven years, enterprises’ quick moves to the cloud also meant that some things got damaged along the way – including security.

Our recent survey conducted with the Cloud Security Alliance showed that more than half of organizations are now running over 41% of their workloads in public clouds, compared to just one quarter in 2019, and this will increase further by the end of 2021. Enterprises are moving fast to the cloud, but they are also finding that things are getting broken during this process.

The research showed 11% of organizations reported a cloud security incident in the past year, with the three most common causes being cloud provider issues (26%), security misconfigurations (22%) and attacks such as denial of service exploits (20%). In terms of the business impact of these disruptive cloud outages, 24% said it took up to three hours to restore operations, and for 26% it took over half a day.

As a result, it’s no surprise that organizations have significant concerns about enforcing and managing security in the cloud. Their leading concerns were maintaining overall network security, a lack of cloud expertise, problems when migrating workloads to the cloud and insufficient staff to manage their expanded cloud environments. So, what are the root causes of these cloud security concerns and challenges, and how should enterprises address them?

Confusion Over Cloud Control

When asked about which aspects of security worried them most when running applications in public clouds, respondents overwhelmingly cited getting clear visibility of topologies and policies for the entire hybrid network estate, followed by the ability to detect risks and misconfigurations.

A key reason for these concerns is that organizations are using a range of different controls to manage cloud security as part of their application orchestration; 52% use cloud-native tools and 50% reported using orchestration and configuration management tools such as Ansible, Chef and Puppet. However, nearly a third (29%) said they use manual processes to manage cloud security.

In addition, there’s competition for overall control over cloud security: 35% of respondents said their security operations team managed cloud security, followed by the cloud team (18%) and IT operations (16%). Other teams, such as network operations, DevOps and application owners, all figured in, too. Having different teams using multiple different controls for security limits overall visibility across the hybrid cloud environment, and also adds significant complexity and management overhead to security processes. Any time you need to make a change, you need to duplicate the work across each of these different controls and teams. This results in security holes and the types of misconfiguration-based incidents and outages we mentioned earlier.

How to Move Fast and Not Break Things

So how can organizations address these security and management issues, and get consistent control over their cloud and on-premises environments, so they can take full advantage of cloud agility and scalability without compromising on security? Here are the four key steps:

Get holistic visibility across your networks: a lack of visibility across cloud estates was the main security challenge for survey respondents. Organizations need to get holistic visibility across all of their different cloud accounts, including the security controls that are being used both in the cloud and to manage traffic to and from the cloud environments. This enables IT and security teams to quickly identify any potential security issues or risks that could lead to outages.

One management console to rule them all: When using a mix of the cloud providers’ security controls as well as other controls, both in the cloud and on-premises, it’s a huge challenge for organizations to manage policies consistently. If all these diverse security controls are managed from a single console using a single set of commands and syntax, security policies can be applied consistently. This avoids duplication of effort and the error-prone manual processes that lead to misconfigurations and outages. It also provides a full audit trail of every change.

Automate security and compliance processes for speed: Automation is essential to managing cloud environments efficiently while orchestrating changes across a complex array of security controls. It brings speed and accuracy to managing security changes across cloud environments. It also accelerates audit preparation and helps ensure continuous compliance. Automation also helps organizations overcome skills gaps and staffing limitations, which were cited as a challenge by over three-quarters of our survey respondents.

Accelerate incident response, anywhere: Our survey also showed organizations are concerned about overall network security in the cloud. Security management solutions that integrate with SIEM or SOAR tools can help to address these concerns by accelerating incident response. As soon as a threat is detected by the SIEM or SOAR product, the management solution can identify all the applications and servers that the threat could impact. The solution can then mitigate the threat’s risk by automatically isolating any affected servers or devices from the network – whether in the cloud or on-premises – preventing lateral movement.

With a network security automation solution handling these steps, organizations can get holistic, single-console security management across all of their public cloud accounts, as well as their private cloud and on-premises deployments. This helps them to solve the cloud complexity challenge and ensures faster, safer and more compliant cloud management – making it possible for organizations to move fast in response to changing business needs without breaking things.

May 27, 2021
Rethinking Your Tool Chain in the Cloud
Every IT shop has a “tool chain” – all of the software other than the OS and the application that fills in the gaps and keeps everything running. This includes solutions for monitoring the application, data protection, software development, release management, provisioning and de-provisioning resources and more. These tools build up over time, often evolving from homemade solutions to commercially available software as the company grows.

The cloud presents another inflection point: a new way to manage systems and applications. When a company is considering moving applications to the cloud, IT and application development teams should take the opportunity to reevaluate their tool chain. Are their existing solutions still the right fit in this new cloud-based world, or are there better alternatives available? Here is a process for making that decision, and some important questions to consider when assessing whether a change is in an organization’s best interests.

Step One: Take Inventory of the Current Tool Chain

First, IT teams should perform a full inventory of their current stack to ensure they don’t overlook anything. This audit should include the following areas:
- Provisioning tools (like Ansible or Terraform).
- Identity and access management (IAM) solutions that allow IT to restrict access to servers, resources and software to only relevant users.
- Development tools including IDEs, continuous integration/continuous delivery (CI/CD), source control and more.
- Data protection, high availability, disaster recovery and backup software.
- Monitoring and auditing software (like Datadog).
Step Two: Assess How Well Each Tool is Meeting IT’s Needs

Next, consider how well each product is meeting IT’s needs now, and how those needs will change as workloads move to the cloud. The first and most important question: is the tool and/or version you’re on still supported by the vendor? Changes like this migration to the cloud are rare, so the likelihood that one or more products are no longer supported is higher than one might think. Second, consider the licensing terms of the software and whether they allow for its use in the cloud. For instance, some tools are licensed to a specific physical server and some vendors require their hardware to be owned by the same entity which holds the license. Neither of these scenarios work well in the cloud. Third, will the application be managed in the same way after the migration? The cloud typically removes constraints; it offers nearly unlimited compute and storage, dynamic workloads, new APIs and multiple regions around the world. IT teams may want to take advantage of these capabilities by moving to a cloud-based tool (replacing an on-premises application log reporting solution, for example), or they may want to keep management as consistent as possible to minimize the amount of retraining required for employees.

Don’t forget to consider non-technical arguments. Is the team happy and productive with the current solution, or do they feel forced to use it? Is it meeting the business needs of the organization? Will the change create more work in the short term? These reasons aren’t enough to keep a tool on their own, but they should be part of the discussion.

Step Three: Create a Map of Alternatives

Next, look at the potential alternatives to the tools that may need to be replaced. This can be a good opportunity to consolidate, so start by looking at what other teams in the organization are already using in the destination cloud. The most common decision IT must make here is whether to switch to a cloud-based tool (either one offered by their cloud vendor or a separate SaaS product). These typically offer pay-as-you-go licensing and are usually easier to scale up or down, move workloads around and to expand to other regions. Licensing for legacy vendors varies widely; some now offer consumption-based options to compete with the cloud, while some are sticking with perpetual licenses. These factors may make a cloud-based tool more or less attractive for specific companies based on their needs. Last, consider if making a change would allow the IT team to expand their skill set. For engineers that like learning new things, adding new products could actually increase satisfaction and retention because it gives them a chance to learn something new.

Step Four: Talk to Existing Tool Vendors

Even if a different option seems like the better choice, it always pays to check in with the current vendor and give them a chance to keep your business. It’s possible they may offer more flexible terms to keep you as a customer. The opposite is also possible; some vendors won’t budge on their licensing because they see the cloud as a threat. Even if a vendor conversation doesn’t change what they are willing to offer, it will usually reveal useful insight about how they approach their customers.

Step Five: Create a Plan for Each Tool

Based on the information gathered in the last four steps, it is time to decide what to do with each tool and make a plan for each transition. Where necessary, note products that will need to be replaced soon, ones where more research is required, and compile any other useful information learned during the process so that the larger IT team can access it. Also consider if teams will need training, if internal documentation or playbooks need to be updated, and how new tools will plug into existing authorization/authentication solutions. Each change will also need a migration plan of some kind that details how and when the organization will move from the old product to the new one, what scripts will need to be rewritten and what to do with historical data like log files from the old product.

Cloud-based tools won’t be a fit for everyone, but their flexibility, potential cost savings and ease of scalability shouldn’t be underestimated. While no one is eager to add more work to a cloud migration project, taking the time to go through this process could uncover useful new options that better fit the new cloud model that the business is moving toward.
May 25, 2021
Automation is Needed for Reliable Cloud Platforms

From six to 1,400 microservices in less than five years? At first glance, that sounds like overwhelming complexity. Can you actually see the entire system across all of the microservices? This is the key to highly available and reliable SaaS cloud platforms. But what does this mean, and how can SaaS providers achieve it?

Over the past decade, the cloud has become the virtual space where the majority of companies’ business processes and communications take place. Considering the accelerated digitization processes of the last year alone, cloud computing plays an increasingly crucial role when it comes to making distributed teams more productive. As a result of these developments, the number of applications, microservices and interfaces is increasing, creating a more complex IT infrastructure.

The reliability and availability of cloud services must, therefore, be a high priority for providers. Weak services and downtime not only cause frustration among customers, but can also lead to considerable financial losses on the customer side. Accordingly, SaaS providers must establish processes and methods that help them provide secure and highly reliable cloud infrastructures, or risk losing their customers.

Microservices as the Foundation for Reliability

Complexity is implied with every SaaS cloud platform. This can be managed in two different ways. On one hand, management can be done via a centralized monolith. Through this, complexity arises from a single system with only one interface to external systems. On the other hand, complexity can be distributed via smaller system units in the form of microservices. This means that the various functions of an application or service are broken up and assigned to several individual instances that communicate with each other. The advantage of this is that if a microservice fails, the entire application is not necessarily affected.

Microservices in cloud environments have been enjoying steadily growing popularity for some time now. In fact, 76% of the companies surveyed as part of a 2019 Forrester study stated that microservices will be high on the business agenda for many companies in the future. Only 4% disagreed with this statement at the time. In 2020, a TechRepublic survey found that the majority of experts surveyed (73%) have already integrated microservices into their application processes, and 66% of respondents use them in the form of cloud services. Microservices are everywhere!

Service Level Objectives and Automation

Due to the numerous interfaces that arise with microservices and the need to be monitored, this architecture appears, at first glance, to be more error-prone than traditional monolithic systems. Some companies already rely on service level objectives (SLOs) – i.e., targets and measurable KPIs to ensure service quality – for a higher level of security. However, these are often limited to the outer layer of the entire system.

Formulating appropriate SLOs for each microservice with additional alerts can counteract this. In combination, these provide profound protection of the system against creeping errors.

In order to maintain an accurate overview with regard to security and security-related incidents, and thus ensure the reliability of the system, the microservices and their respective SLOs must be closely monitored and continuously tested. When we surveyed software and IT professionals back in 2019, we found that 71% of respondents reported that microservices-based architectures are much easier to test than monoliths. And with the help of automation, operational teams can ensure that the overall reliability level is close to 100% in every single instance of the systems, no matter how complex. A separate, centralized automation tool monitors all microservices in use and is able to alert appropriate teams about any abnormal activity with respect to individual breached SLOs. In addition, this tool should be linked to an incident management platform so that any breach can be remediated directly. By following this framework, software developers will enjoy the benefits of a more manageable and scalable microservices system.

We live in a time when consumers expect technology to be updated regularly and run reliably. If this is not the case, they will simply opt for better alternatives. To prevent this, companies need to invest in more effective service structures. Microservices, combined with a central platform that automates testing and management, is the foundation for achieving reliability and scalability.

May 24, 2021
The Importance of NetSecOps in Network Management

The IT landscape has changed beyond recognition in the past decade or so. The vast majority of businesses now operate largely in the cloud, which has had a notable impact on their agility and productivity. A recent survey of 1,900 IT and security professionals found that 41% of organizations are running more of their workloads in public clouds when compared to just one quarter of respondents in 2019. Even businesses that were not digitally mature enough to take full advantage of the cloud will have dramatically altered their strategies in order to support remote working at scale during the COVID-19 pandemic.

However, with cloud innovation so high on the boardroom agenda, security is often left lagging behind, creating a vulnerability gap that businesses can little afford in the current heightened risk landscape. The same survey found the leading concern about cloud adoption was network security (58%).

Managing organizations’ networks and their security should go hand-in-hand, but, as reflected in the survey, there’s no clear ownership of public cloud security. Responsibility is scattered across SecOps, NOCs and DevOps, and these teams don’t consistently collaborate in a way that aligns with business interests. We know from experience that this siloed approach hurts security, so what should businesses do about it? How can they bridge the gap between NetOps and SecOps to keep their network assets secure and prevent missteps?

Building a Case for NetSecOps

Today’s digital infrastructure demands the collaboration – perhaps even the convergence – of NetOps and SecOps to achieve maximum security and productivity. While the majority of businesses do have open communication channels between the two departments, there is still a large proportion of network and security teams working in isolation. This creates unnecessary friction, which can be problematic for services-based businesses that are trying to deliver the best possible end user experience.

The reality is that NetOps and SecOps share several commonalities. They are both responsible for critical aspects of a business and have to navigate constantly evolving environments, often under extremely restrictive conditions. Agility is particularly important for security teams to keep pace with emerging technologies, yet deployments are often stalled or abandoned at the implementation phase due to misconfigurations or poor execution. As enterprises continue to deploy software-defined networks and public cloud architecture, security has become even more important to the network team, which is why this convergence needs to happen sooner rather than later.

We somehow need to insert the network security element into the NetOps pipeline and seamlessly make it just another step in the process. If we could automatically check whether network connectivity is already enabled as part of the pre-delivery testing phase, that could, at least, save us the heartache of deploying something that won’t work. And then, if we do need to open new ports, an automated process that could also raise a change request would save even more time. Better yet, if it’s one of those “make this like that” changes, the change could be automatically implemented on the firewalls – in minutes, not weeks.

With NetSecOps, application developers can get creative without worrying about security slowing them down, and network security teams can sleep soundly, knowing that risk and compliance checks are built in to the continuous delivery process with a full audit trail, so they can even get time back to do some fun stuff.

If we could do all this with only the rare cases of new connectivity requiring approval by security, the NetSecOps dream could become a reality, allowing fast, high-quality delivery. With NetOps and SecOps working together, organizations can establish a collective approach to network management and security, offering equal opportunity for both teams to present and prioritize issues and agree on the fundamental rules from the start; a match made in heaven.

May 24, 2021