devopsy.kinsta.cloud

Tag: IT security

Four Trends Defining the Observability Market in 2023

Observability is a market that has grown exponentially over the past few years. It started as a buzzword in late 2015 and early 2016, and since then we’ve seen dozens of insurgent companies rush in, eager to stake their claim in a new (albeit loosely defined) market. Incumbent companies also rebranded their wares, hoping to capture some of the momentum that comes from the new term.

Venture capital saw the market opportunity, too. By my conservative estimate, observability companies raised nearly $2 billion over roughly the last two years alone (I’m including some cybersecurity companies, which I’ll explain later).

In the seven or so years since its inception, the observability market has fragmented and specialized into categories such as application, data, network and edge observability. On the artificial intelligence and machine learning side, there is model observability and AIOps. Connecting it all are observability pipelines.

While more businesses than ever know about observability and have built it into their tech strategy, category awareness still has a long way to go. And though the dollars were flying fast and furious a couple of years ago, the economic cycle has turned against risk, and growth funding rounds are harder to come by. It’s time to step back and examine the key trends defining today’s observability market.

Staffing Shortages: A Blessing and Curse to Observability

Many companies in the observability space, regardless of their subcategory, represent net-new work for IT and security teams. A new application performance monitoring (APM) platform may offer a marginal improvement around APM’s golden signals, but that marginal improvement is a substantial lift for the end users tasked with implementing and deploying the new platform. While software may get sold, overworked ITOps and SecOps teams may decide the effort isn’t worth the perceived ROI, leaving the software on the shelf.

On the other hand, observability products that reduce toil for operators will continue to outpace market growth rates. IT departments face acute shortages in skilled staff, leaving companies with little choice but to seek out software that automates high-effort, low-value tasks or otherwise offers a force multiplier to existing teams. Subcategories like AIOps and observability pipelines can address those needs.

Consolidation is Needed to Simplify the Market

Another looming hurdle for the nascent observability market is feature similarity between companies in a subcategory. Two subcategories where this is apparent are application and data observability. In the application observability space, several companies were founded in the wake of the availability of extended Berkeley Packet Filter (eBPF) technology. eBPF allows you to extend the capabilities of the Linux kernel at runtime, and a common use case is to trace applications running in user space. While this is a great technology with several uses, there are simply too many companies with the same idea, the same go-to-market strategy and same limited feature set.

Data observability is another subcategory riddled with clones. Data observability started as a reaction to operational brittleness in the modern data stack, and there are only a few companies with marked differentiation here. I agree with Matt Turck’s assessment that data observability products will drift into the well-defined (but arguably less sexy) data quality category.

CFOs are Looking to Reduce Tool Sprawl and Cut Costs

The challenges with raising growth rounds have been well documented. VC funding represents the supply side of the finance puzzle and IT budgets are the demand side. The demand side is getting squeezed as CFOs clamp down on budget growth. Deals are taking longer to close and often involve more parties eager to reject a budget request from another team because it means more money for their team.

A common refrain from CFOs today is that any new spending must be more than offset by corresponding savings somewhere else. This puts the products representing net-new work with little marginal utility at risk. Observability vendors today need a strong consolidation (e.g. can reduce tool sprawl, serve multiple teams, etc.) and cost savings story to survive in a difficult budget climate.

Cybersecurity remains a budget bright spot. According to a recent survey from IDC, 27% of respondents stated cybersecurity budgets were immune from budget cuts. With changing SEC rules highlighting the need for board-level cybersecurity expertise and reporting of breaches, coupled with the new National Cybersecurity Strategy, the priority around preserving these budgets is clear.

Cybersecurity is Pure Greenfield for Observability

A few short years ago, SecOps teams, threat hunters and incident response teams didn’t have enough data to create an accurate picture of their environment. Endpoint data was sparse and incomplete, cloud-based application deployments were still uncommon, the network remained between the office and data center, and so on.

Today’s SecOps teams, threat hunters and incident response teams have too much data to understand their environment. There are too many alerts and too little context, making finding the signal through the noise a difficult, if not impossible, proposition. From a compliance perspective, much of this data must be retained for longer periods, driving up storage costs.

This is where the principles of observability benefit cybersecurity teams. Much like site reliability engineers need to trace an error well after it occurred, cybersecurity professionals need to trace a breach or find threats over huge volumes of data. They need robust exploration tools, rational data storage and routing options, and, most of all, the ability to do this while maintaining budgets. This is where observability and cybersecurity converge.

Seven years young, observability remains a nascent market despite its rapid growth. Though the market will face growing pains, the opportunities and upside are bright.

May 15, 2023
Codenotary Previews Secure SBOM Creation Service

Codenotary today made available a preview of a centralized repository service for generating and storing software bills of materials (SBOMs) that makes it simpler to securely share them as necessary.

Moshe Bar, Codenotary CEO, said SBOMCenter will make it easier for organizations to operationalize SBOMs that are being created with greater frequency as the need for increased focus on securing software supply chains grows.

Currently available as a free trial, Codenotary’s SBOMCenter provides a way to create and store SBOMs in a way that ensures they have not been tampered with, noted Bar.

Implementing SBOMs can be a cumbersome process that can require changes to existing software development and procurement practices. The SBOMCenter provides a service for accessing SBOMs that are continuously updated using an immutable open source database that supports multiple SBOM formats and a tool the company developed that automatically generates SBOMs by adding a single line of code. That approach should make it simpler to identify what software components are running in a production environment any time a new zero-day vulnerability is discovered.

In a future update to SBOMCenter, the company said it plans to add vulnerability scanning, risk exposure scoring, alerts on newly discovered vulnerabilities and a policy enforcement engine that can be integrated with DevOps pipelines.

Awareness of the need for SBOMs has increased dramatically since the Biden administration’s executive order made it clear that federal agencies would require them from any software provider starting next year. Many enterprise IT organizations are likely to follow suit as part of a larger effort to better secure software supply chains in the wake of a series of high-profile cybersecurity breaches.

More recently, a National Cybersecurity Strategy paper published by the White House calls for increased liability for software developers that fail to exercise due cybersecurity diligence when building applications. It’s not clear if there will ever be a law on the books that would enable penalties to be applied, but the general mood is clearly shifting toward holding organizations that build software more accountable for cybersecurity issues that might arise.

It’s not yet clear how far down the path organizations are toward operationalizing SBOMs. Gartner predicted that, by 2025, a full 60% of organizations will be employing SBOMs. In theory, those organizations should be able to prevent software with unverified components from being deployed in production environments and identify which applications currently running have significant flaws.

On way or another, application providers will find themselves disclosing more about how their software is constructed. The issue now is finding a way to accomplish that goal in a way that respects intellectual property rights. As such, application providers need to find a secure way to share SBOMs with customers that will commit to making sure the contents of those SBOMs stay private. After all, a little cooperation from the coalition of the willing is likely to have a more positive impact than a law that is likely to be challenged.

April 27, 2023
Business Leaders Will Trade Speed for Security

A global survey of 600 C-level executives conducted by CloudBees found that when it comes to building software, more than three-quarters of respondents said it is more important to be secure and compliant than fast and compliant.

As a result, more than three-quarters (77%) also noted their organization is implementing a shift left strategy for implementing security and compliance even though 58% recognized that those efforts created additional burdens for developers.

Three-quarters of respondents also conceded that compliance (76%) and security (75%) challenges limited their company’s ability to innovate. Nevertheless, 83% said shift left is important for them as an organization despite the fact that 88% of executives said their software supply chain is secure or very secure. However, only 33% of respondents said their software supply chain is completely compliant.

Not surprisingly, 86% are focusing on compliance more now than they were two years ago and, in the wake of a series of high-profile breaches of software supply chains, 82% are more concerned about attacks.

CloudBees CEO Anuj Kapur said it’s clear there is a greater need to reduce security and compliance burdens for developers by putting guardrails in place that automate DevSecOps processes. The survey noted that only 22% of executives believed their software delivery supply chain is completely automated, while another 37% said it is close to being automated. Only 22% said their compliance process is completely automated, with 35% believing it is almost completely automated.

Three in five (59%) executives said they have all, or mostly all, external tools for security and compliance issues and 29% said they have a mix of internal and external tools. Only 11% use mostly internal tools. A full 90% said their risk management team has the tools, knowledge and expertise to build and/or maintain a secure software supply chain.

The real challenge, of course, is that while compliance issues are relatively static, new security issues arise all the time. Developers make mistakes or a new zero-day vulnerability is discovered after an application has been deployed in a production environment. It’s critical for organizations to embrace automation to enable developers to address those issues as part of a continuously automated update cycle, noted Kapur.

As more responsibility for compliance and security is shifted left, the degree to which DevOps workflows will need to be adjusted will naturally vary by organization. However, the days when developers could ignore security issues during the application development process are all but over. The leadership of organizations of all sizes are making it clear they want to see a reduction in the number of security and compliance issues that arise in production environments.

Ideally, efforts to build more secure and compliant applications would not slow down the rate at which applications are being built and deployed. However, the CloudBees survey made it clear that more executives are willing to prioritize security and compliance over speed of application development. The issue is how to strike a balance between what are clearly two competing priorities.

October 3, 2022
Tips for a Successful DevSecOps Life Cycle

A DevOps implementation, if done correctly, can do wonders for any organization that’s on the hunt for efficiency, productivity and speed. As per the 2020 survey conducted by Atlassian, 99% of survey respondents said that DevOps has had a positive impact on their organization.

However, it won’t do any good if security isn’t prioritized while adopting the DevOps best practices. That’s where DevSecOps comes into play.

Enterprises need to understand that leveraging the alignment of development and operations for workflow enhancement while ignoring underlying security issues is like trying to generate electricity from a broken solar cell on a cloudy night. Undoubtedly, the success of any DevOps initiative predominantly relies on general security practices and a robust security mechanism to mitigate risks—this is where DevSecOps plays a vital role.

There are several essential components of a successful DevSecOps implementation. Here’s how you can leverage them in your organization.

The Emerging Need for DevSecOps

DevOps can be simply defined as the next evolution of an agile development environment that bridges the gap between operations and development teams. Enterprises increasingly are turning to DevOps to boost their application development speeds and operational efficiency. Often, though, prioritizing development velocity means security concerns are left behind.

That’s why there’s an equally growing need for a secure, efficient yet still agile development environment. DevSecOps puts security at the forefront of the entire operational and development process, which safeguards good cybersecurity hygiene right from the beginning. Implementing DevSecOps directly benefits developers and operations teams working hard to deliver a flawless application in a short period of time. Moreover, this approach encourages enterprises to develop secure code and thus, secure applications. To do so, there are several resources and strategies to help implement DevSecOps into an organization’s software development life cycle (SDLC).

Secure Coding Practices

Secure coding is perhaps the most crucial aspect of ensuring stringent security right from the beginning of the SDLC. Developers who aren’t following secure coding best practices, security guidelines and maintaining compliance while coding the application are inviting many security risks, including breaches of sensitive data and exploitation of an individual’s identity.

Hence, an organization must focus on enhancing the skills of developers and ensuring that they are following security best practices while their application is in the initial stages of development. Moreover, establishing and adherence to coding standards are also crucial, as they help application developers to write clean code.

Leveraging Automation

As we know, automation is a driving force and a key aspect in DevOps; the same goes for DevSecOps. Automating security is vital to keep up with the pace of application code delivery, especially for more prominent organizations working on various code versions. Choosing the right automation testing tools can be beneficial for organizations that wish to speed up their operations and enhance the reliability of code when it comes to security. Organizations should strongly consider using at least static application security testing (SAST) tools that help developers identify potential vulnerabilities in code in the early stages of the development life cycle.

Early Stage Testing

The biggest mistake for any organization leveraging DevSecOps is testing the application only when it’s finally completed. Beginning early with automated testing offers numerous advantages, including identifying and resolving vulnerabilities in early development stages, a quick and inexpensive way to fix issues and saving valuable time during deployment.

However, testing during the early stages of the SDLC may also halt the overall DevOps development pipeline, so take that into consideration from a security perspective.

Implementing DevSecOps

Implementing DevSecOps isn’t a quick process and requires specific steps to get it right.

Planning and Development

A solid planning strategy for successful implementation must include test criteria, design, vulnerability models and analysis. Once the planning is complete, the next step is development. Development teams should initially evaluate the overall complexity and challenges of their current practices. Adding a code review system in the development process can help to encourage safe and reliable coding practices in a DevSecOps environment.

Build and Test

Now it’s time to build! You can use automated tools to help combine source code with machine code; many of those build automation tools offer security features like automatic vulnerability detection. Once the build is complete, rigorous testing is carried out through various automated testing frameworks that ensure the highest level of performance and security.

Monitoring

Monitoring is another crucial aspect of DevSecOps implementation to ensure your security mechanisms are performing up to snuff.

Undoubtedly, DevSecOps has revolutionized the way enterprises handle security, especially in challenging DevOps environments. Businesses that want to get to the next level of agility without sacrificing robust security should be implementing DevSecOps.

October 4, 2021
AIOps Greasing the Wheel of Digital Security amid COVID-19

Amid the most challenging era for business infrastructures and transformations, AIOps (AI for IT Operations) can help industries operating in the digital environment to be vigilant when it comes to network operations or the digital security measures.

AIOps has the potential to significantly align well with the cybersecurity needs of a company. A cybersecurity department in every organization needs to be active with respect to the latest and innovative security-related solutions. Threat detection and data security are crucial for every business entity.

The corporate networking infrastructure for communication purposes is always under the threat of unauthorized third-parties that try to access confidential communications. Whether they are wireless, wired or connected to internet of things (IoT) devices. AIOps, through its intelligent algorithms, detects the communication requests and their source to accept them and restrict the fraudulent entities from becoming part of the legitimate network. Visibility and speed are two important aspects of platform security. If the source of the incoming request is known, it would be easy to verify it.

The following are some of AIOps applications:

Regulatory Framework

General Data Protection Regulation (GDPR) corresponds to the protection of online customer data online. Businesses are required to ensure enough security measures to protect the personal and financial information of customers stored in an online account from identity theft and data breaches. AIOps can be used to secure the data from unauthorized third-party access in order to comply with the regulatory requirements.

Real-time Data Processing

In this era, communications, connection, data transmission and storage activities are performed online. Real-time data collection and processing in AIOps help streamline the operations and ensure the security of platforms in a centralized database. Technologies are shaping future investments. Enterprise management with respect to the performance attributes such as data analysis and monitoring for controlled access are in high demand. Advanced automation techniques have become possible with the innovative AIOps that help undergo operations in efficiently, eliminating the time-consuming and frustrating manual tasks. Machine learning and artificial intelligence algorithms collectively help reduce the overall response time, provide optimal user experience and protect network systems.

Applications of AIOps amid the COVID-19 outbreak pave the roads for leading challenges. The rapid digital transformations during the pandemic are giving birth to various challenges with respect to security, user experience and the downfall of industries. Businesses are revamping operational infrastructure and fraudsters are actively exploiting vulnerabilities in the digital environment. The density with which the fraud is increasing each passing day is high. AIOps, under these circumstances, help businesses take into consideration vigilant security measures. The innovative solutions employ AI algorithms for the security of online platforms.

Information Security and AIOps

Information security highlights three major factors: confidentiality, integrity and availability. Confidentiality takes into account the need for protecting confidential customer information. Integrity keeps the form of data intact and availability ensures that the data is present at the moment when it is required. AIOps help ensure this CIA triad of information security through its high potential applications online security.

High-scale data breaches, identity theft, account takeover frauds, malicious executables injection and similar cyberattacks are due to the uncontrolled access over user accounts and data. The list of fraud calls for stringent actions that AIOps provides in the form of digital security. The AI-powered identity verification systems help verifies the identity of customers online before onboarding them. Biometric sign-in every time while accessing the accounts help mitigate the risk fo fraud and bad actors that become the reason for malevolent activities. The spoofing detection and prevention techniques use AIOps that identify the spoofing elements in user-uploaded identity proofs and discard their communication request, which in return curb the likelihood of cyberattacks.

July 13, 2020
Who’s Responsible for Security? Apparently, It Depends

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

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

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

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

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

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

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

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

The Blame Game

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

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

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

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

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

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

How DevSecOps Can Work

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

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

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

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

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

June 2, 2020
DevSecOps: A Renewed Commitment to Secure Delivery, Part 2

If done right, DevSecOps eliminates the cultural roadblocks that often prevent organizations from getting IT security proactively involved with development and operations. Barriers are the last thing any organization should contend with when comprehensive security is an absolute priority at a time when data breaches, intellectual property theft and other cybercrimes can almost immediately cripple a business.

Still, companies are far from perfect. Misunderstandings, ill-defined policies and turf wars can prevent development and operations from collaborating in a way that naturally bakes-in security into their work. To effectively transform a DevOps pipeline into a DevSecOps one, organizations need to change the way people work and collaborate; make processes inclusive of quality, security and compliance activities; and integrate the right tools.

Those three steps are the focus of this two-part series on becoming a true DevSecOps enterprise. We reviewed processes in part one and now we’ll cover people and tools in this article.

For enterprises with deep-rooted DevOps, a renewed focus on security might entail modernizing the release pipeline and involving IT security people even more. For enterprises that are modernizing heritage-monolithic application portfolios and moving to cloud native architectures, pipeline modernization should include a DevSecOps approach that considers containers, microservices and APIs.

DevSecOps done right gives organizations a level of visibility and accountability that helps accelerate coding, testing, production deployments, problem determination and defect resolution–all accomplished because of an organization-wide acceptance and commitment to security that should shatter any and all roadblocks.

Don’t Forget About the Humans in DevSecOps

When was the last time you heard a developer say, “Hey, let’s get the security guys in here, to hear what they have to say?” Reality is far harsher. Collaboration with IT security often triggers visceral reactions that are not exactly positive. IT security is often stereotyped as the organization of “no” and “you can’t do that.”

DevSecOps aims to tear down those cultural barriers. DevSecOps is all about embracing your IT sec organization and even inviting auditors to collaborate early on in the release process.

Ultimately, security is everyone’s responsibility. Being a developer, there was nothing like the mention of security to make me feel super uncomfortable. I don’t believe that developers set out to purposely create insecure code. However, when IT sec is not involved in a collaborative, cooperative relationship with dev and ops, there is an uncertainty that creeps in, and trust and confidence are shattered.

We know developers develop and release code, while operators control and manage the runtime environment. What is the expectation of IT security in this process? What are they looking for? What risks do they need to mitigate when a digital product is delivered? Understanding the objectives of IT security in the delivery process will clarify the steps that must take place in the process and reveal which tools should be used to create a product that’s secure and delivered with velocity and quality.

Understanding what stakeholders do along the pipeline reconciles personal and organizational accountability with tangible value-add in the release process. DevSecOps can be a catalyst to re-examine and provide clarity on who is doing what, when it is being done and why the effort is being exerted.

Clarity might reveal that personas need to be updated to more modern roles. For example, an operations system administrator might become more of a site reliability engineer (SRE). The SRE role involves more proactive activities, earlier in the release pipeline, to infuse greater fault tolerance in code and greater resilience in the environment configurations–and to solve problems by engineering solutions with developers and IT security.

Determine who does what and where. Develop personas that outline responsibilities along the pipeline, from the sourcing of code to production, to create necessary transparency. Value-stream mapping is a good way to capture the current state of a release pipeline and an excellent way to construct a desired state pipeline with the necessary people performing value-add activities to releasing a product.

Use Tools that Provide Necessary Visibility

Tools are the enablers. These are the cogs in the machine that will be running test cases, static analysis, vulnerability scans and integration tests. Tools will automate DevSecOps processes and provide the most critical function: visibility. The ability to observe all DevOps processes and determine their origins in the pipeline is critical. Visibility lessens risk and supports compliance and audits. The process that defines how code is governed through the promotion path should drive the tools that will be integrated into the release pipeline. Most tools serve to automate build, testing, scanning, movement through the promotion path and integration with other tools. It only makes sense that end-to-end visibility in the release pipeline should be engineered in.

Tools, though, must integrate and communicate to achieve end-to-end visibility. In the heritage era of DevOps (basically, the time before cloud native), it was tough to gain visibility because tools came from different vendors and often couldn’t talk with one another. Fortunately, cloud native platforms offer more integrated capabilities. Build and CI tools naturally share information because these capabilities are being refactored into the cloud platforms themselves.

An example of this is the cloud native CI/CD capabilities of Tekton, which leverage and extend the operator framework in Kubernetes. Translation: CI/CD tools are starting to look like extensions of the cloud native platform, in stark contrast to heritage CI/CD tools which were standalone third-party software products. The result of this tool trend is tighter integration and better visibility built into the platform–you don’t have to engineer it.

Companies need to review how effectively their tools communicate and close any visibility gaps. When possible, consider some of the next-gen automation tools and technologies such as Tekton, Kabanero.io and Jenkins-x that bring greater visibility, integration and consideration for cloud native apps which heritage tools have struggled with.

DevSecOps Is a Catalyst for Pipeline Modernization

A modern security framework will let companies take full advantage of the cloud native technologies that are changing DevOps. Granted, most companies won’t completely shift their entire infrastructure to the cloud, nor should they. Most organizations need to identify a partner to help them assess which processes and tools are worth moving to the cloud, and which ones–like a mainframe that runs core business functions–should be left alone.

For those enterprises that have a large heritage application portfolio, DevSecOps could mean retrofitting automation into systems and applications that were often designed and developed without the scaffolding of a secure DevOps pipeline. DevSecOps applies to heritage application, too. After all, what pipeline wouldn’t benefit from the visibility and traceability of tracking a user story to its production release? By automating the delivery of these heritage apps, you’re optimizing the effort of manual activities such as build, test and deploy, and retrofitting the capability of pipeline visibility.

Cloud has changed the DevOps game, newly defining the fundamental technical underpinnings of what an application really is. And it is cloud that’s driving companies to look at the security of DevOps in an entirely new way. With much on the line–the purity of products, compliance, brand reputation–companies need to rebuild their security frameworks so they can take full advantage of cloud and their on-premises programs. They don’t have to do DevSecOps alone.

— Andrea C. Crawford

February 20, 2020
DevSecOps: A Renewed Commitment to Secure Delivery, Part 1
Security has never been as high a priority than it is today, as companies fear they’ll be the next headline, the next victim of a data breach. Executives also worry about applications meeting the high standards of compliance–either with global regulations such as GDPR, state-oriented privacy laws or the many specific ones covering finance, health care, energy and other industries.

It’s a bit of a challenge introducing new tools and processes into a longstanding software development life cycle, even when it’s for the sake of increasing security. That’s why companies need to first carefully review their development and production processes to fully understand how they create and release software before they can effectively integrate security into DevOps.

A reconstruction, so to speak, of application delivery allows companies to step back and smartly modernize their pipelines so there’s minimal human interaction or machine disconnect in newly secured DevOps processes. Involving IT security as a stakeholder in defining governance in a DevOps release pipeline is also crucial. Only then does the “Sec” fit nicely into DevSecOps. In this two-part series, we’ll look at the three critical components that shape a sound DevSecOps pipeline. They are easy to remember: processes, people and tools.

Vulnerabilities Call for a Maniacal Focus on Security

Although microservices, containers and cloud-native architectures enable companies to create and deliver applications more nimbly and faster than ever before, many of these innovative technologies also increase the probability of security flaws and vulnerabilities in products. Exposure to risk is much greater with applications being released at higher frequency and in higher quantity as smaller containerized deployment units, as opposed to development happening on a gated monolithic Java application.

For example, the provenance of images from public container registries can be compromised and thus a potential exposure point in development. Likewise for the proliferation of open source software that is often used as libraries and dependencies. Perennial tools, such as GitHub, have fostered sharing and open communities, sometimes with grave consequences to those contributors that publish sensitive data to public repositories. How many times have we heard about passwords being pushed to public repos for all the world to see?

With all those considerations in play and with so much at risk, companies now have a maniacal focus on securing DevOps. But before they can even start formally considering security, they should first review employee responsibilities, organizational accountability, delivery practices, governance and the other aspects that go into the design, development and delivery of digital products. For enterprises that are modernizing to cloud native platforms and technologies, it might be an opportune time to reexamine and freshen up approaches.

DevSecOps is indeed about people, processes and tools. Fully understand those three and you can build a secure delivery process that engenders trust and confidence in DevOps. Trust and confidence foster accountability and the notion that digital reputations are everyone’s responsibility.

Determine the Process for the Release Pipeline

Here, it’s about cementing a formal governance of processes, all the steps behind an application moving from one point to another. How does code graduate from local development and testing to the production station–and what happens in between? This is a fundamental tenet of the plain ol’ DevOps of yesteryear.

There are notable considerations in a cloud native pipeline. For instance, the promotion path might be described with Kubernetes namespaces and clusters (not the baremetal servers or VM environments of yesteryear). Another modern DevOps approach is to apply DevOps principles to the application and environment configuration artifacts. Also known as GitOps, it’s applying the use of version control, access management and lifecycle processes to yaml files, helm charts, monitoring scripts and other artifacts that are primarily a concern of operations. Extending DevOps to operations (or GitOps) mitigates risk in environment misconfigurations and configuration drift, an added benefit. Security, in this respect, is addressed through environmental compliance.

Aim to justify everything that happens in the release pipeline. Examine the value-add of steps and align them with the security risks they are trying to mitigate. Here are some examples:
- Unit tests must pass in the build phase of the release pipeline to mitigate the risk of non-working code being pushed to the Development environment and entering the promotion path.
- Vulnerability scanning must occur on all Docker images prior to go live to mitigate the risk of a security flaw or vulnerability being introduced in production.
- All API interfaces must have a Swagger definition and a set of corresponding Pact/contract tests run in build phase to mitigate the risk of integration defects and corresponding outages.
Seek Answers, Document Everything and Include Security

By questioning everything, the answers will reveal what falls under the security lens and what eludes it. Ultimately, you want to document practices and processes so that they’re codified and held with reverence by everyone along the pipeline. IT security should have a seat at the table (alongside development, operations, product owner, QA) and be an equally important voice in examining the release pipeline. A core agile value is to have a product-focused approach to the release pipeline. Involving IT security will bring a healthy measure of risk mitigation into the pipeline, while still considering velocity in delivery.

But that’s just the process. As we’ll explore in the second part of this series, people and tools also make a difference.

— Andrea C. Crawford
February 5, 2020
Moving Security Beyond SSH and PKI

SSH (secure shell) is still the most common method of remotely accessing a Linux server, which makes it a common target for attackers attempting to infiltrate corporate networks. While the protocol itself carries a number of advanced security properties, it does allow for human error, opening the door for unwarranted privileged access to sensitive company resources.

Keeping track of all valid credentials across a company is something that IT departments continually struggle with. The stakes are high if they fall into the wrong hands, essentially handing over the proverbial “keys to the kingdom.” A recent study by Dimensional Research found that 90 percent of respondents do not have a complete and accurate inventory of all SSH keys, and 63 percent don’t actively rotate keys, even when an administrator leaves the company.

Managing privileged access to servers has always been a rigorous exercise in key management. There are a number of best practices to follow to avoid the many common pitfalls, such as storing private keys in a vault service or maintaining a strict rotation policy, but they don’t get to the crux of the matter: The credentials are static. Here’s a (not so) crazy thought: What if we got rid of them entirely? Static credentials are a thing of the past, representing the failed perimeter model of corporate security.

Problems with Traditional PKI

The traditional PKI (public key infrastructure) that backs SSH was built for a different time, when a key exchange meant enough to grant trust. Without a proper authentication process, there is no clear way to attribute to a person, nor a feasible way to provide any historical context. As these keys get issued and distributed across fleets of infrastructure and cloud services, the challenge only compounds. Each public key accrues more privileges over time; the longer it’s been alive, the more likely it’s been shared with a resource, making it extremely difficult to track and subsequently revoke. With this model, time is a bug that can’t be fixed.

Authorizing a specific request should also go beyond the mere presence of the public key within the authorized_keys file of the server. Independent of authentication, authorization is about who should and should not be able to access a specific server from a known device, and what permissions they have on the machine. You may have a policy that states only members of the engineering team can only access a production server through a bastion host. Adhering to that policy in practice, however, is impossible without a proper authorization process.

Enter Zero Trust Security

We’ve come to a consensus across the industry that the network perimeter is breaking down in the modern cloud era. It’s time to take that one step further and agree on a new model of trust attestation to match, where decisions are removed from the network layer and handled correctly at the application layer. Flipping the model around like this means starting with zero privileges by default, and only granting access to a resource once a request has been fully authenticated and authorized. Verify, then trust—the mantra of Zero Trust.

Google’s BeyondCorp is the marquee example of Zero Trust done right, an internal initiative meant to better secure how employees access corporate resources. The end result is a carefully crafted distributed system that makes real-time trust decisions based on what is known about a user and their device, allowing the thousands of Googlers across the globe to work securely from any location without the use of a VPN. BeyondCorp is just one example, and we’ve seen more and more companies start to adopt a similar approach.

Ephemeral Client Certificates

The thinking behind ephemeral credentials is that a request triggers independent authentication and authorization processes, where a trust attestation is made against the policies of the resource. If valid, a single use credential is issued, which is used to initiate a secure session with the resource. This credential is tightly scoped to the specific request, rendered useless in any other scenario.

The fundamentals of this workflow can be accomplished through a client certificate-backed PKI architecture. Client certificates became a supported feature of OpenSSH in 2011 with the introduction of version 5.4. Unlike standard SSH keys, which carry no metadata, certificates are cryptographically verifiable metadata objects that can inject information such as usernames, roles and more. Time now becomes a feature because the scope of the credential truly represents a dynamic attestation of trust.

The fine-grained access controls inherent in a client certificate-backed PKI architecture solves for the problems with SSH keys because the credential can be tied to an actual user. The threat vector of lost, stolen or misused credentials is also eliminated, saving managers from the numerous headaches associated with SSH key management.

To put these ephemeral credentials into action, you need to surround the client-certificate PKI with the supporting access controls. Companies with the means can build their own system similar to Google’s BeyondCorp, but this is no simple task, as you need to operate your own Certificate Authority along with a distributed system capable of performing dynamic authentication and authorization against policies in real time.

About the Author / Ivan Dwyer

Ivan Dwyer is the VP of Product Marketing at ScaleFT, working with the community to raise awareness around BeyondCorp and Zero Trust for organizations of all kinds looking to modernize their security architecture. Connect with him on LinkedIn and follow him on Twitter.

December 5, 2017
Q&A: Michael Beckley, CTO/CCO, Appian

Recently I had the chance to speak with Michael Beckley, chief technical officer and chief customer officer at Appian, about his company’s move to go public and the DevOps space in general. For those of you who don’t know Michael, he is a founder of Appian and leads the company’s technology vision and oversees customer initiatives worldwide. He also serves on the Industrial Advisory Board for the University of Virginia’s Computer Science Department and is a member of the University of Maryland Advisory Board in Computing. He has an interesting take on the IT space and DevOps in particular. Read on for our discussion.

Alan Shimel: Michael, what do you think has been the “special sauce” that has led to Appian’s success to date?

Michael Beckley: With Appian, companies build unique business applications up to 20x faster and mobile-enable and modernize existing systems. For example, a company like Ryder was able to build a web and native Android tablet application that cut the time it took to rent a truck in half.

But the “special sauce”? That’s Appian’s culture of innovation. Our engineers think long-term and invest in breakthrough tech like our patented SAIL UI technology for zero code native mobile apps. Thanks to SAIL, the web apps you configure in Appian automatically deploy to iOS and Android as native, full-featured apps or specialized micro apps we call “Sites.” As long as we get the culture right, we expect to continue to deliver enduring value for our clients.

Shimel: With becoming a publicly traded entity, some companies have found “managing to the street” does not match their own long-term business plans and their customers needs, how does Appian avoid this?

Beckley: Companies, like people, are an aggregation of their habits. Appian’s habit has always been to hold to our long-term vision of enabling every company to be a software company. We are not your typical Silicon Valley tech company. Our roots are in DC, we largely bootstrapped this business, and learned to be good stewards of capital while helping to support the core missions of federal agencies and some of the world’s largest brands. The proceeds following this IPO will be invested back into our business to benefit our customers.

Shimel: What do you see post-IPO being the biggest areas for growth as it relates to new products and services?

Beckley: We plan to invest in innovating and enhancing our platform. While our platform is industry-agnostic, we have recently made, and plan to continue to make, investments to enhance the expertise of our sales and marketing organization within our key industry verticals of financial services, health care and government. We have made, and will continue to make, investments in research and development to strengthen our platform and expand the number of features available to our customers. As we continue to increase the functionality of our platform and further reduce the amount of developer skill that is required to build robust applications on our platform, we believe that we have the potential to expand the use of our platform.

Shimel: Digital transformation is a term that is being used a lot these days. How far along the adoption curve are we on digital transformation?

Beckley: While many speculate that digital transformation is just a tech industry buzz word, in reality, digital transformation is a living, breathing effort. According to a recent survey, digital transformation is a C-level priority and is considered a top focus for almost 50 percent of all companies this year. From Appian’s perspective, we believe that the utilization of low-code software to drive digital transformation is still relatively new and our customers will be able to succeed in their digital transformation efforts by incorporating low-code development.

Shimel: Where does the DevOps market intersect with the Appian business model?

Beckley: Organizations are turning to DevOps to accelerate development and bring an application’s capabilities to a user quicker. The Appian low-code development platform fits into the DevOps model and supports the seven major DevOps categories including code, build, test, package, release, configure and monitor.

Overall, our business model supports the DevOps market; we’re living in a world where citizen developers are playing such an important role in the enterprise and our platform empowers the citizen developer while alleviating developer resources to focus on the more challenging, business-critical developer work.

Shimel: What about containerization and microservices? How do these technologies affect Appian?

Beckley: Appian already uses containers and microservices. Appian’s enterprise customers often require a mix of cloud, hybrid cloud, and on-premise installations. We view containers and microservices as enabling technologies to support the diverse workloads and deployment models required by our enterprise clients.

Shimel: What about security? What challenges does cybersec pose to Appian’s development of their platform?

Beckley: Appian works with some of the nation’s most important and highly regulated industries, therefore we have built a comprehensive security and compliance structure that meets several industry standards. We frequently undergo third-party audits to ensure that we are always operating effectively to protect our customer data.

— Alan Shimel

June 7, 2017