devopsy.kinsta.cloud

Tag: security

  • 5 Steps to an Open Source DevOps Strategy

    5 Steps to an Open Source DevOps Strategy

    Open source technology thrives during times of mass disruption, and this pandemic has been no different. Across the board, companies are accelerating their digital transformation and DevOps strategies, looking to open source technology as a way to streamline operations. While deploying open source software (OSS) in DevOps can help organizations lower costs and avoid vendor lock-in, the tools are often not backed by an ecosystem that makes them transferable across the enterprise, leading to interoperability issues across the board and creating a haphazard workflow.

    Before embarking on an open source migration, companies need to plan out their strategy. Following these five steps will help companies create an organized plan and a seamless open source stack so that they can capitalize on the lower costs and tap into the benefits of the open source community.

    Determine if you Can Self-Support Your Strategy

    A recent Gartner study determined that at least 75% of open source policies don’t yield effective results. This stat is largely due to companies believing that they can self-support their open source stack. However, as technology becomes increasingly complicated, companies should take a step back and evaluate if they actually have the right resources and skill sets to get the job done. Enterprise architects with open source expertise are a niche group that’s in high demand, so don’t worry if you don’t have the resources – there are plenty of trusted vendors out there who have a proven track record of delivering results.

    Consolidate

    Fewer vendors equal fewer problems. When evaluating potential partners, keep in mind that working with a few key partners (versus several) will be beneficial in the long run by ensuring that applications will work together seamlessly, while also avoiding vendor finger-pointing if they don’t. Assess potential partners to see which packages, application stacks and infrastructure they support, and what level of freedom you have to switch out various components. Avoiding vendor lock-in is key, as switching vendors will be a costly undertaking if you ultimately decide to go in another direction.

    Invest in Security

    Security is a major concern in enterprise open source software, and it’s critical to make sure you have the ability to act quickly on potential issues and vulnerabilities. Consider partnering with a vendor who specializes in OSS security, and can keep clients informed of the latest security updates and bug fixes to ensure that your program isn’t vulnerable to security threats. Having a security specialist on standby is a must-have for organizations so that when security is breached, it can be remediated immediately.

    Pick the Right Tools

    Not all tools are alike. There are plenty of options out there that can help elevate your open source strategy, but consider how each will affect your overall program. At each phase of your pipeline, test the open source tools selected to ensure that they can integrate together within the broader toolchain and every layer of your software stack, including databases, platforms and monitoring solutions. If you have questions about their connectivity, either consult with an expert who understands how the software will truly behave in various environments or engage with free apps that help developers determine if their tools are compatible across the broader stack. Doing so will help enterprises choose the right open source technology early on, saving both time and money.

    Adapt

    Open source implementation in DevOps is more than a one and done approach; it requires adapting and tweaking in order to stay relevant, keep a competitive advantage and optimize new technology. Ensure that your open source strategy can be improved to include new offerings and services that the company will implement down the road and that your vendors—or internal team—can modify the framework fairly easily when necessary.

    While open source technology continues to drive innovation in the DevOps industry, including it in a company’s DevOps strategy requires thoughtful planning. When done right, an open source policy will save a company time, money and people power, allowing them to collaborate seamlessly with the greatest minds in the industry.

  • DevSecOps Implementation: It’s About the Data

    DevSecOps Implementation: It’s About the Data

    It seems we are constantly barraged with, “So-and-so announced that their systems had been breached and 80,000 user records were stolen,” notices. In fact, https://haveibeenpwned.com/ lists ten billion hacked accounts.

    That is no surprise. Databases exist to pool related data together. Even NoSQL type databases, which some saw as an opportunity for wildly disparate data to be gathered and analyzed, almost exclusively contain related data sets. We generally don’t want or need to correlate, say, the number of pirates in the world with annual global temperatures, for example.

    One would think, with decades of experience under our belts, we would have a good solution for protecting that data. If it was a simple problem, we would. It is not.

    Databases are the primary target of most attackers. After all, getting access to your user database gives them account names through which they can try and gain elevated privileges. Getting a large amount of user/credit card information gives them a revenue stream by selling them off (though it is now so common that prices on the black market have become depressed, and this isn’t really profitable, given the risk versus the reward, anymore).

    And databases must, by definition, have broad access. A database does not exist in a vacuum; it exists to serve an app. For server-based databases, it almost always exists to serve multiple apps. It must be on the corporate network (even if that network is a virtual private cloud), and it must … offer up data. It has users that have greater privileges than your average customer, and is notoriously difficult to protect with strong protections like encryption.

    Encryption poses problems at multiple levels. It is still a bit slow, for starters. This is the nature of the beast – if it takes X microseconds to respond to a request, encrypted data will take at a minimum X+decrypt time (regardless of where decryption occurs). If encryption is done by column, index fields cannot be encrypted (because “nZ19?SDF” is unlikely to be in the same sort order as “ford explorer”, for example) Which means some data is immediately excepted from encryption. If encryption is handled by the database system, then the time overhead exists, and the database system must send the resulting data over your network … unencrypted. I was involved in a couple of projects that required encrypted databases – the one I can vaguely talk about was putting information about your corporate network onto Android and Apple devices. Needless to say, since phones and tablets are misplaced quite often, and most have weaker security than your average laptop, we needed information about critical infrastructure to be encrypted. It was … painful. We only managed it successfully because corporate networks are finite resources, so the amount of data we needed to store was limited, and we could prove performance wasn’t going to be the issue.

    So what can you do? Continue to follow attempts to adequately encrypt corporate databases. Eventually, someone will crack this problem in a way that is performant, can be debugged and reliably protects the data.

    Until then, protect your databases. Use the tools we’ve talked about in this series to monitor and protect the entire network, knowing that the database is a high-profile target if someone gets in. And use the other security tools available. The major database vendors offer DBMS security tools to evaluate your current status. Some will flag weak passwords, others will monitor for injection attacks (as will development tools discussed in the first few installments of this series). Lock down interfaces to databases – by user, by IP, whatever makes the most secure, but still usable, environment for you. Set up monitors for behavior outside the bounds of normal behavior – a query of 250K records should raise a flag, for example, since the vast majority of apps will only do a subset that can be paginated. Sure, it will probably be a false positive caused by someone hand querying, but the one time it isn’t, you’ll be glad the monitor was there.

    And protect your database backups – be they actual backups or a dump to test. Fewer organizations are using real, unfiltered data for testing, but it crops up in most orgs at one point or another, as testers are trying to look at issues that fake/masked data can’t replicate. For actual backups, those must be encrypted. To lose your customers to a hacker because you had an unencrypted database dump lying around, and the attacker didn’t even have to attack the DB, is downright shameful, and happens too often. Along these same lines, and this should go without saying, but it’s happened enough that I feel compelled,  do not copy large chunks of your database out to an unsecured cloud storage bucket. Some vendors have addressed this issue by not allowing public unsecured buckets, but you can still do this, depending on the cloud you are using. So, don’t.

    The database security market will be best served by being rolled into SIEM and/or XDR. And while I’m in full-on pundit mode, for this statement, I’ll predict that is where it is headed. Database security is as much about overall security as it is the database, so overarching systems are the best place to detect and defend from. So watch for moves in that direction. A holistic view will serve you better in the long run.

    Meanwhile? Keep rocking it. Treat your data like gold, because to hackers, it really is. And, keep running the world’s business. Celebrate your successes as much – or more – than you learn from your failures.

  • DevSecOps Implementation: EDR/XDR

    DevSecOps Implementation: EDR/XDR

    We mentioned host intrusion detection and network intrusion detection in an earlier blog, and mentioned firewalls a couple of times in passing. Let’s delve a bit into the history to understand how these tools’ functionality has evolved over time.

    On the host side, we had virus detection, in one form or another, from early in the evolution of the Internet. The idea being that, if an antivirus program could scan your files, it could help protect you from malicious applications. Applied to an organization, if antivirus applications could scan all users’ desktops, it could help protect the organization. And it did kind of work. Most organizations were protected, at one point or another, by their antivirus software. Then, they realized the need to see more than what simply scanning files could show. A file that looked innocent on disk could assemble malicious code while executing, so runtime environments also needed to be watched. Generally speaking, the same antivirus companies led the charge into runtime protection. But there is more to protecting systems than simply looking at running applications. Scripts, even database entries, could be made malicious, and activity over time could indicate a bigger problem than a virus – an intrusion. This problem was the reason host intrusion detection was born. The idea that all of your system(s) needed protection all of the time created a mostly agent-based environment that monitored several aspects of the running system to watch for suspicious activity.

    On the network side, firewalls were implemented early in the growth of the Internet to allow limited access to corporate resources over the network. If no one ever needed to telnet to the machines on subnet X, the telnet port for subnet X could simply be blocked at the firewall, and no sleep need be lost over attempts to connect. Almost immediately after their inception, firewalls started logging attempts to access ports, and this information was made available to network administrators to review. This had an interesting impact on the management of hosts, because now, the firewall could inform network administrators if one of the internal hosts was constantly attempting to do something it shouldn’t be – possibly indicating an intrusion or a bad employee (more often than not, it turned out that undertrained, curious employees were just poking around). But firewalls – whether using whitelist or blacklist methodology – were fragile and/or interruptive. They also simply plugged holes in the perimeter without being proactive. That is when some bright people realized that, if you monitored streams running through the firewall, you could detect attacks and intrusions and offer admins proactive information about potential threats. That was the genesis of network intrusion detection (at least, as with all of these, as much of it as I can cram into a blog).

    But as time has moved on, there was a need for more. Network intrusion prevention was tried, but most organizations don’t want automated systems cutting off connections for fear of impacting real users. While it is still around, it hasn’t gained all that much traction. The next step was to “connect the dots,” so to speak. If the HIDS on host A was detecting a suspicious pattern of behavior, it only made sense to have the HIDS on the other hosts in the network take a look for similar behavior. Command and control of cross-HIDS installs is at the heart of endpoint detection and response (EDR), which gathers information from multiple HIDS agents and correlates it to get a more holistic view and alert on activity that a single host might not have noticed (a super simplified example: if the same user account tries to get super-user privileges with a single attempt on a dozen machines. HIDS might not raise a high-priority alert for a single attempt, but EDR sees twelve attempts on twelve different machines, not just the one on a given box, and can raise a high-priority alert).

    Extended detection and response (XDR) extends this information amalgamation and analysis to the network side, including attempts to gain access to the network (in our simple example above, imagine if the same user account tried to ssh into machines it doesn’t have network access to).

    As of this writing, EDR and XDR are using machine learning (ML) to perform faster processing of all the data they are seeing, and to limit false positives while raising critical alerts up to human operators. At this point in the ongoing feud between attackers and security personnel, I’ll go so far as to call it state-of-the-art. For now. Other attack vectors and XDR-defeating attacks will no doubt come along, and will have to be answered, but for now, if you have a publicly exposed network, it is the best you can get. Vendors have moved both EDR and XDR analysis to the cloud, ostensibly to improve analysis. It does reduce the amount of maintenance customers must perform, but cloud usage comes with an operational pricetag that prospects should understand before signing on the dotted line. Most mid-sized or larger organizations don’t have a storage or processing power shortage, so operational efficiency is what you are really paying for, in most cases. Make sure it’s worth the cost, and you have a plan if you lose access to that ML engine in the cloud.

    Meanwhile, keep kicking rear. Mark each day with, “At least we’re not SolarWinds,” and, remember: you’re doing your best to protect the org in a dynamic and hostile environment. Celebrate each day without a breach as a success – because someone did try.

  • DevSecOps Implementation: SIEM

    DevSecOps Implementation: SIEM

    The world is filled with events. Our inbox floods with events that marketers really want us to pay attention to, while news feeds flood us with events they’re trying to raise above the background noise, but then, the dog barking interrupts our consumption of that information. Our family is, meanwhile, texting us about events on the family level that may be related to events on the national or world stage … meanwhile, social media is full of garbage information about events that may or may not be real, and that you may or may not care about.

    We ignore the vast majority of these inputs and move along with our day. The inputs that require our attention usually, but not always, get it. Sometimes, we fail horribly at filtering, judging importance, or both, and it has life-impacting ramifications.

    This is not too far from the state of security event management when security information and event management (SIEM) was born. Disparate feeds were coming in from all over; analysts – be they dedicated security folks or systems administrators wearing an extra hat – had to guess which of dozens, hundreds or even thousands of events were a real threat to the environment.

    The first step to gaining control of that environment was standardization and aggregation. Get the events into one place, with similar information available for similar events. That was where SIEM came from.

    Since then, the number of events coming in has continued to rise. Companies that were seeing hundreds of events a day are now seeing hundreds an hour, and SIEM vendors had to keep up. The complexity of attacks, and the ability to detect them, has gone up, and SIEM vendors have had to keep up. Tools available for feeding the SIEM and for acting on the aggregated data have evolved … and SIEM vendors had to keep up.

    At this point in time, SIEM is best characterized as a data aggregation platform with limited intelligence that aids in filtering of irrelevant events. It’s akin to turning off social media and telling those close to you to call if needed; it filters out the worst noise and elevates the most important messages.

    Other tools can analyze their own data and make their own deductions, but SIEM is where you bundle all security-related events in one place, so it is the logical place to filter the noise and raise awareness. But it requires a high-volume, adaptable datastore. Vendors have reached that plateau.

    Once volume issues were mastered, SIEM vendors turned to helping filter the insane volume of security event noise. Yes, it is a security event if Bob logged in on a new workstation, but it probably isn’t a noteworthy security event. Unless Bob’s new workstation is in a country where the company doesn’t do business, or Bob is still logged in on his own workstation, blissfully unaware of the other login.

    So, rudimentary filters were applied to the event data in the SIEM. This got rid of a huge amount of noise. Next came filtering events that, logically, looked like notable security events, but just weren’t. Something was scanning ports on the firewall. An internal firewall. Sounds bad, unless the security tools’ logs showed that an authorized user kicked off the scan. Then, it’s a simple matter of asking the user in question, “Are you scanning X?” and moving along. It’d be better for the system to lower the importance of the event based on the fact that it is an authorized user doing the scanning, with corporate-approved tools. Then, an analyst may not need to get involved at all (my security friends are cringing because, literally, they trust no one, and would point out that authorized users can misuse tools, too – so I’ll note that here).

    But the event volume kept going up, and the analysts were even more swamped. Between adding new reporting apps (HIPS alone can add thousands of reporting points to a SIEM), and increases in events on existing monitored points, it was ugly.

    Enter AI. This is when machine learning (ML) started becoming the norm in SIEM. Now, we want the system to avoid using hard-and-fast rules that must be maintained, but to use knowledge it gains by watching the flow of data and an analyst’s resolution to selectively raise/lower the priority of events. Now, the events that actually bubble up to analysts are ones that the ML engine sees as fishy, and the number is greatly reduced. False positives still occur, but not nearly at the volume they did before, as the system learns how to detect them.

    But wait! There’s more!

    All that data in one place with ML engines crawling over it was just too much temptation for data scientists and deeply knowledgeable security personnel. So, the ability to plot a course through seemingly unconnected security events and determine that this or that was actually evidence of intruder or attacker activity spread across the system came next. This is where we are now – the ability to connect the dots on events that analysts (or the system) might have filtered out to find patterns that indicate intrusions.

    But it comes with a price. It’s not cheap to set up, it’s not easy to train, and maintenance of a system that takes inputs from everywhere and tries to correlate the resulting dataset is … work. We’re not talking a little bit of data here, and, like the environment it comes from, we’re not talking a little bit of complexity. Do you need it? I would say yes. Even if you only use SIEM as a big data store, it will help you perform post mortems when (not if) you have a breach. It is worth the effort, unless you are tiny or have no Internet presence to speak of.

    Keep rocking it! SEIM is another tool to consider as you move to DevSecOps dominance, but again, just a tool that requires you to keep the org safe.

  • DevSecOps Implementation: Intrusion Detection

    DevSecOps Implementation: Intrusion Detection

    Originally, this series was just going to be four articles on the DevSec side of DevSecOps. There are many reasons for this, but primarily because that side is cleaner. The other reason is that these topics are beyond the work we were doing at Accelerated Strategies Group.

    But we’ve had a number of requests to continue, and I’ve used many tools in the space, so on we go.

    Intrusion Detection

    Intrusion detection (IDS) started because attackers were getting through firewalls, and, once inside, seemed to have free rein. Intrusion detection wanted to offer another option for detecting and stopping attackers by watching things inside the firewall for indications your organization had been compromised. Relatively quickly, intrusion detection was supplemented by intrusion prevention (IPS). The idea of prevention was to proactively make changes based upon known issues to keep intruders out. Intrusion detection offered information about what paths attackers were exploiting, and intrusion prevention would plug them. Note that IDS and IPS are often further subdivided into host-based (HIDS) or network-based (NIDS) systems. Since their role – detection of intruders – is the same, for this overview we will discuss them together. A serious deep dive into IDS/IPS should look at HIDS and NIDS separately.

    In the DevSecOps space, some have folded these into security monitoring, but they are still performing the same basic tasks – just much better. In fact, if you found intrusion detection to be limited and clunky to work with because of rules maintenance and fingerprinting issues, it’s probably time to take another look. Here’s why:

    Problems With Traditional Intrusion Detection

    The problems with pure rules-based intrusion detection were two-fold.

    First, rules were hard and fast.

    “Look for X and Y and Z. If all are present, raise an incident.” This tended to result in only two types of rules – ones that were too narrow, and thus brittle, or ones that were too broad and that buried IT/security staff in alerts.

    Second, those rules were outdated before they hit the network.

    The old adage “You are always fighting the last war,” (meaning you are doing what worked the last time you won) is more true in IT security than almost anywhere else. For a rule or a fingerprint to be assembled, it has to have been seen. That means we were perpetually protecting against previously successful attacks and doing little against emerging threats. Security vendors took a lot of steps before coming to our current solution, which is a great step in the right direction.

    Attacks against IT infrastructure share a lot of commonalities. Purely rule-based systems counted on tribal knowledge to code those commonalities into rules. It was clunky and imperfect. Templates helped, by adding common items based upon the type of rule you were creating, but, like rules, they tended to be static and old news.

    Enter Machine Learning

    Bright people with an eye on the ever-changing environment knew that we needed something that could adapt to multiple attack forms/vectors and draw the type of conclusions that security analysts were tasked with. The ability to reduce the number of alerts that get raised is pretty close to miraculous. Anyone with a web presence sees thousands of security events a day, as attack bots and scanners automate chunks of the attack matrix. Some kind of solution to weed out the false information is nearly mandatory, as no organization has the manpower to monitor at those levels and reasonably follow up on threats.

    Machine learning (ML) makes connections between alerts – that might not be a big deal in isolation – and other events that, together, make a case for human intervention. Added to fingerprinting and rules, it is a powerful addition. While a successful attack would require going through rules and making certain you covered the behavior/changes found in the new attack, ML can take that information in and adapt automatically.

    This is cranking through volumes of data we couldn’t even imagine a decade ago, and finding anomalous behavior, correlating it and alerting where necessary. How much it reports up the chain is generally configurable, allowing an organization to tighten the flow of alerts that analysts have to deal with.

    Go With the Flow

    More recently, flow evaluation has become a positive step in the monitoring process. If this connection/user moves from A to B to C, it might be an attack. This allows for another way to rate suspicious activity and raise it to an analyst’s awareness.

    An increasing number of vendors are moving the analysis portion of these activities into their hosted environment. This is a “great strength/great weakness” solution – putting the data points gathered from your system into their cloud allows them to correlate events and improve all customers’ responses. The other side of the coin is that you are paying them operational costs each month, and for most vendors, you’re charged based on how much of the service you use. This has budget implications. It also assumes you have connectivity to their service. If you don’t, for any reason, no analysis will be done on collected data. A careful rollout and contingency planning are in order for this scenario to be successful.

    Integration with security information and event management (SIEM) systems is ubiquitous. We’ll talk about SIEM next; I just wanted to include here that IDS/IPS vendors are feeding SIEM.

    IDS isn’t perfect, and there are a ton of other things out there to help, but it’s a step in the process, one you should consider as you gear up your DevSecOps to professional levels. Some of you are using the tools, but don’t have them integrated into your DevOps systems. This is a nudge to do so. If resolution of an attack automatically creates tickets for Dev to make the code (or ops to make the config) more secure, it absolutely is a plus to the organization responding proactively.

    Keep kicking it. These are just tools, and they’re useless without you. Figure out what your organization needs, and update those needs regularly as the environment (both attackers and architecture) continually changes around you.

  • DevSecOps: Bringing Compliance to DevOps

    DevSecOps: Bringing Compliance to DevOps

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

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

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

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

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

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

    The Benefits of Collaboration in DevOps

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

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

    Closing the DevOps Communication Gap

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

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

    Integrating Sec Into Dev

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

    DevSecOps: Greater Unity, Stronger Security

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

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

  • Cloud Growth and Other 2020 Trends

    Cloud Growth and Other 2020 Trends

    Growth continued this year as even the COVID pandemic could not slow down the cloud

    The rise of COVID-19 defined 2020 for nearly every industry. Cloud computing is no exception, though growth in the sector continued this year. Gartner estimates that $257.9 billion will be spent on public cloud services in 2020, up 6.3% from 2019. IDC reports that almost half of IT spending is cloud-based, “reaching 60% of all IT infrastructure and 60% to 70% of all software, services and technology spending in 2020.” These projections came in mid-2020, which proves that cloud adoption and spending were not greatly impacted by the pandemic.

    You can make the argument that cloud computing itself is the trend of 2020. Blockchain, quantum computing, machine learning and AI all deservedly earn a lot of headlines in the tech press. But at a more basic level, cloud computing is changing the way we do business. Whether it is the way they store their data, improvements to agility and go-to-market for faster release of new products and services, or how they develop and operate services remotely in today’s “locked-down world,” cloud computing is benefitting all businesses in every sector.

    In short, cloud computing had a strong year in 2020 despite COVID-19 and appears to have a very bright future. Several key trends, perhaps overshadowed by the pandemic, helped define a dynamic year for the sector. These include the following:

    • Continued Dominance of ‘The Big Four’ – All of the big four cloud providers—AWS, Azure, Google Cloud and Alibaba Cloud—reported strong growth and collectively grew 40% in Q320. Together they still account for 63% of the entire cloud sector.
    • Rise of Managed Services – The global cloud managed services market, in particular, is growing rapidly and is expected to reach $116 billion by 2025, growing from $62.4 billion in 2020, according to a study conducted by Markets and Markets.
    • Serverless and Containers – There used to be some talk about serverless and containers replacing the use of traditional virtual machines (VM). But I mostly see customers realizing that VM infrastructure is not going to disappear anytime soon, though container use certainly rose over the last 12 months.
    • Automation – The push toward greater automation continued in 2020. I noticed users accepting greater automation in their infrastructure environments, and there was simply more demand for it across the board. This is great news as one of the major advantages of a DevOps approach is automating away the manual tasks that bog down critical projects.
    • Growth in home use – This may seem an obvious one, but with the COVID-19 pandemic leading companies across the globe to new “work from home” policies, virtual desk infrastructure (VDI) usage exploded.
    • Security – Especially with a remote workforce, cloud security faced new challenges this year. One example of this playing out is in Snowflake’s massive IPO.

    Other trends of note this year included the continued growth of hybrid and multi-cloud and desktop as a service (DaaS). So, while COVID-19 truly defined 2020 for most people, the cloud sector was busy with the trends discussed above. It will certainly be interesting to see how these trends play out in the year ahead. Whatever new trends arise, it seems likely that cloud computing will continue to transform the way we all do business.

  • XDR: The DevOps Transformation of Security Infrastructure

    XDR: The DevOps Transformation of Security Infrastructure

    eXtended detection and response (XDR) is a security technology that unites multiple security systems into one. Organizations are transitioning from traditional systems such as endpoint detection and response (EDR) and security and information event management (SIEM) to XDR, in a move that is analogous to the transition from agile to DevOps work processes.

    XDR can detect threats quickly by automatically collecting and combining information from across the IT environment—endpoints, servers, email and social media messages, cloud and application workloads—giving security analysts the context they need for fast investigation and response.

    In many cases, attacks occur in the borders between security silos. Each silo may be adequately protected by a security solution, but in between those silos, attacks remain evasive because security analysts have a limited view on the environment, determined by their security tooling. XDR connects silos with a unified threat identification and response strategy.

    Just like in the past development and operations teams were responsible for separate silos, with independent tooling and split responsibilities, security teams are split into silos, with limited communication between them. Security threats that cut across silos are difficult to mitigate. XDR enables new organizational structures in which security teams work together, with shared responsibility for mitigating threats, no matter where they occur in the IT environment.

    Benefits of XDR

    The purpose of XDR is to promote the visibility of threats and security incidents throughout an organization’s ecosystem. Its key benefits include:

    • Centralized monitoring and management – XDR solutions provide a single pane of glass for security incidents happening across the corporate network, endpoints and workloads. Consistent security rules can be implemented across diverse IT infrastructure, both in the cloud and on-premises.
    • Unified visibility – XDR integrates security visibility  across endpoints, cloud infrastructure, network traffic, etc. This allows security analysts to understand potential security incidents without having to learn and use other platforms.
    • Fast ramp up – XDR offers built-in integration with an organization’s IT infrastructure, and uses multiple threat discovery mechanisms from a variety of security technologies. Because analysts only need to learn one platform, time to value dramatically increases.
    • Increased productivity – XDR eliminates the need to manually switch between multiple dashboards or tools to collect security data. This allows analysts to more effectively detect and respond to security threats.
    • Low Total Cost of Ownership (TCO) – XDR provides a fully integrated network security platform. This can reduce the costs associated with purchasing, configuring and integrating multiple solutions.
    • Analyst empowerment – XDR provides a shared workflow for all tiers in the security organization. This reduces the need for training and allows Level 1 analysts to perform more in-depth analysis, reducing their need to escalate to higher analyst tiers.

    XDR is designed to give security teams full visibility into an organization’s endpoints and network infrastructure. Increased visibility has many security benefits:

    • Unified detection and remediation – XDR provides centralized and integrated incident response capabilities across all corporate environments. This allows security personnel to quickly identify threats, mitigate them and recover, all using the same platform, reducing the impact on the organization and overhead costs.
    • Better understanding of threats and attacks – Attack indicators are rare and far between, and each one on its own may not be enough for analysts to identify the threat. XDR collects these signals from multiple sources, across environments and over time, helping analysts identify threats that would otherwise remain invisible.
    • Threat hunting – With unified visibility and data analysis accessible to everyone in the security environment, all analysts can carry out proactive analysis to identify threats that have already compromised the corporate environment.

    How Does XDR Work?

    What is the real difference between an XDR system and the traditional toolchain of endpoint detection and response (EDR), security orchestration, network protection and data analysis tools?

    The answer is the language it uses. An effective XDR system should provide a unified, abstracted language to describe security signals, data and security controls. This language clearly specifies the potential security associations of each data point, by adding the concept of an “attack history.”

    The XDR security language removes certain non-essential information, but suppresses noise, revealing high-risk attacks. It does not require expert manipulation, so security analysts do not need to be interpreters anymore—they can spend their time actually mitigating attacks. It is easy to understand, rich with context and content, based on advanced technology, but generating straightforward outputs that make an analyst’s job easier.

    This unified security language is new, because the technology needed to enable it was not available until recently. Here are some of the advanced technologies that have recently matured and power the XDR information experience:

    • Threat intelligence feeds – Now delivered in real-time and with more data and context.
    • Next-generation machine learning – Multidimensional traffic algorithms that take into account signals from many independent data sources, unlike traditional systems such as user and event behavioral analytics (UEBA), which had a narrow set of inputs.
    • Natural language processing (NLP) – Algorithms that can be trained to draw conclusions from security rules, revealing information about threats, security alerts and how they interact with security controls.
    • Reasoning mechanisms – Algorithms that identify causal relationships, allowing the system to aggregate data points and automatically generate an attack story. This is a dynamic analysis, not based on predefined rules as with old-school security information and event management (SIEM) systems.

    Mistakes to Avoid With XDR Platforms

    While XDR is widely believed to be the future of EDR and network security, it is a new technology and there are several pitfalls you should try to avoid in your implementation:

    • High integration complexity – Check the cost and effort involved in integrating the XDR solution with your environment. Maintaining this integration is also costly. For example, if your organization already has a SIEM, integrating it with the XDR system is non-trivial.
    • Time to implement – The adoption time required for an XDR solution is crucial. Organizations are transitioning to remote work, and attackers are using remote workers, unsecured remote devices and networks, to gain access to sensitive data. A detection and response solution that takes weeks or months to successfully integrate into the stack is risky.
    • Limited automated analysis – Some XDR solutions do not leverage the full power of AI-driven analysis, limiting themselves to initial data processing and correlation, which may be better than existing systems, but still require manual work from analysts.
    • Operational complexity – The promise of XDR is to simplify workflows and improve productivity. If the XDR solution itself is too complex or requires analysts to learn new skills, adoption may be difficult and the total cost of the solution increases accordingly.

    An Enabler for DevSecOps

    XDR is not just a technology platform, it is a new organizational model that will help security teams work more closely together, focusing on threats rather than on specific tools or IT systems.

    This ties into a broader movement in security organizations to transition to DevSecOps models, in which developers, security and operations work together to shift security left and integrate security into all parts of the development life cycle.

    XDR technology will make it easier for security teams to act as a whole, and apply security tooling and practices consistently to a variety of environments, from a developer’s workstation to a full production environment. Thus, XDR may become a key enabler for the easier adoption of DevSecOps methodologies in highly secure environments.

  • Speed and Security: How to Find a Balance in Development

    Speed and Security: How to Find a Balance in Development

    Time management can help developers realize the necessary combination of security and speed in application development

    As software continues to create competitive advantages and market differentiation for organizations focused on successful digital transformation, developers will continue to be measured by how fast they can develop and release code. Business leaders encourage DevOps teams to push the pace of innovation to deliver features quickly while leveraging the newest technologies to gain any available advantage in the market. As a result, development and operations teams work at breakneck speeds to meet the deadlines of short and frequent development life cycles.

    Security teams, however, are not measured by speed but rather by certain metrics of success, such as whether they achieve a certain security rating or reduce the number of incidents. Traditionally, security sets corporate standards and best practices centrally and tries to enforce them across the enterprise. With DevOps teams becoming increasingly distributed and decentralized, these conventional security methods no longer work and have actually slowed down security and/or blocked the software development process. Security tries to keep pace, but with numerous disparate reports to review and too many results to manage, they inevitably fall behind. In the rush to catch up, either critical vulnerabilities are overlooked or frustration sets in when releases are delayed.

    Developer and security teams both know the importance of delivering secure software but struggle to find the right balance. Let’s take a look at some strategies that can help ease the tension between DevOps and security teams and create a happier work environment, where safer code is delivered to the market.

    Incorporating Time Management for Speed and Security

    Consider implementing the following time management strategies to make life easier for developers:

    Integrate AppSec in the DevOps Pipeline: Application security scanning should be incorporated early and often within the DevOps pipeline. While this statement may sound like a broken record, the days of running scanning tools independent of your pipelines are gone. Studies have shown the earlier you detect an issue, the easier it is for developers to fix—with as much as 50% time reclaimed over late-stage remediation. By including AppSec in the pipeline, you ensure all issues are identified as quickly as possible. This effort will not only improve the quality of your software but also free up more time overall for developers to write code and create cool features. Sounds like a win-win for both teams.

    Incorporate automation as much as possible: DevOps teams should look to leverage automation when implementing application security wherever possible. Many of the steps for securing your software development process are repetitive. For AppSec to be successful, the steps must work within the developer’s world and along with the other tools developers love. Developers look for tools that help them move faster.

    Here are some areas where application security automation can unburden developers from repetitive tasks:

    • Use AppSec tools that can be easily tied into your DevOps toolchains. As a matter of fact, a developer may not even need to know what security tools are being run, only that they are executed on every run of the pipeline.
    • Automate the ingestion and correlation of the security findings. There will often be a boatload of redundancies between the findings from different security tools (i.e. SAST versus DAST versus SCA) and the potential compression ratios can be in the order of 10-50:1. There are tools to automate this process and dramatically simplify making sense of all the data. The onus shouldn’t be on the developer.
    • Once a security issue has been identified, it should automatically create a ticket in the ticketing system that developers use today. We all know developers don’t like being forced to use a new tool. Give them the findings in the system they are already familiar with.

    Tailor security training for your teams: Security training is a great way to reduce the number of security findings within an organization, which in turn frees up developers to work on other pressing issues. However, most security training is ad hoc and not tailored to meet the needs of the development teams. Even the most basic security testing can provide baseline metrics that enable security teams to recommend tailored training for development teams. These sessions can focus on areas that teams struggle with or areas known to be susceptible. Training is also a great way to develop security champions within the development teams, dedicated professionals who have shown to improve the overall security posture and awareness of organizations. Security champions—and the programs they advocate—have the power to improve both AppSec and relationships among people, a sentiment endorsed by 84% of industry professionals.

    Summary

    Developers know the importance of security and truly want to deliver safe code in the timeframes they are being judged on. By incorporating the strategies outlined above, they will have a fighting chance to reach the lofty goals set by the business, while releasing higher quality and more secure code. Security teams need to meet the developers in their world and help enable application security to be automated and work at the speed of DevOps.

  • How to Foster Collaboration Between DevOps and Security

    How to Foster Collaboration Between DevOps and Security

    DevOps is on the rise. Back in 2018, MarketsandMarkets wrote that it expected the DevOps market to grow to $10.31 billion by 2023. That’s up from $2.90 billion in 2017, with a compound annual growth rate (CAGR) at 24.7% projected for the forecast period. Demand for DevOps solutions and services in response to the need for fast application delivery capabilities would likely help to drive this increase.

    Even so, security issues are introducing some challenges for organizations. A study conducted by the Enterprise Strategy Group and commissioned by Synopsys Inc. found that 48% of respondents had knowingly pushed out vulnerable code into production due to time pressures. Patrick Carey, product marketing director for the Synopsys Software Integrity Group, noted that about half of those respondents had done so “because the vulnerabilities identified were discovered too late in the [development] cycle to resolve them in time.” Such weaknesses elevate the risk of a data breach, and they potentially carry reputational costs for organizations that don’t plug those gaps before they release their products into production.

    These findings beg the question: Why are organizations struggling with their security efforts for DevOps? What’s not working for them?

    This blog post will explore these questions in terms of a cultural divide that exists between DevOps and security teams. After exploring where each team is coming from, this blog post will provide recommendations on how organizations can work to foster cooperation between their security personnel and DevOps teams.

    The Great Divide: Understanding the Issue

    The cultural divide alluded to above boils down to a false understanding of security and its impact on the development process. DevOps personnel are required to work within short development cycles to meet their employers’ evolving business needs. Subsequently, some organizations might interpret security as an opponent to their developers’ speed and respond by sacrificing security for the sake of speed. This decision enables misconfigurations, vulnerabilities and other security weaknesses to make their way into production.

    However, this interpretation overlooks an important reality: Many DevOps teams view security as a nuisance that gets in their way and slows down their work. Retroactive fixes ultimately take time and effort. In response, organizations might hold back on investing in the security of their DevOps processes, thus creating “technical debt” in the event that the work doesn’t get done.

    With that said, organizations have an incentive to rethink how they conceptualize security so that they can avoid these costs and keep their development processes running smoothly. But this raises an important question: How can organizations go about doing that?

    How to Balance DevOps and Security

    First, organizations should work to foster a culture of communication through which security personnel and DevOps team members can learn from one another. One solution to start with is having leaders from both teams “walking in the other team leader’s shoes,” thereby allowing them to share information and discuss their perspectives.

    Such communication will be effective only if personnel understand where the other side is coming from, however. That’s why organizations have an obligation to make their security policies and development workflows as understandable and implementable as possible. With this transparency, security and DevOps can begin to craft a way forward.

    Organizations can help out by encouraging both security teams and DevOps personnel to expand their knowledge. With respect to the former, security personnel have an interest in learning how to frame their message in the right language. It’s important to acknowledge that security teams can speak of potential security issues burdening projects with unexpected work and/or threatening operations’ availability with longer mean response times.

    Of course, security teams need to have a basic understanding of where developers and operations personnel are coming from. They can do this if organizations support them in learning about programming languages and how applications are developed. Subsequently, security personnel can use this knowledge to hold more credible discussions with their Devs and Ops counterparts as well as to properly configure their organizations’ Kubernetes.

    StackRox emphasizes the importance of administrators using automation to review their environments for possible misconfigurations:

    That’s because in a sprawling Kubernetes environment with several clusters spanning tens, hundreds, or even thousands of nodes, created by hundreds of different developers, manually checking the configurations is not feasible. And like all humans, developers can make mistakes – especially given that Kubernetes configuration options are complicated, security features are not enabled by default, and most of the community is learning how to effectively use components including Pod Security Policies and Security Context, Network Policies, RBAC, the API server, kubelet, and other Kubernetes controls.

    As far as DevOps personnel are concerned, training is key. Organizations should specifically consider training their DevOps teams in secure coding practices and educating their employees about attackers’ tactics. These individuals can then incorporate that knowledge into their coding practices and development processes. Additionally, organizations can uphold this security mindset among DevOps personnel by assigning security responsibilities to an individual on the DevOps team or to someone in a new position. They can then overlook security protocols among the DevOps personnel.

    Positive Focus Goes a Long Way

    The key to making security and DevOps teams work together is not taking their collaboration for granted. Like any relationship, organizations need to foster this cooperation by using positive focus and work to bring these two groups together. In that way, they can enjoy both the speed of DevOps as well as the security to stay safe against evolving digital threats.