devopsy.kinsta.cloud

Tag: devsecops

Will DevSecOps Replace the Security Operations Center?
Traditionally, a security operations center (SOC) is a physical facility where an organization performs information security activities. The SOC team analyzes and monitors the organization’s security systems. A SOC aims to protect businesses from security breaches by identifying, analyzing and responding to cybersecurity threats.

The SOC team consists of administrators, security analysts and security engineers. They work in collaboration with internal development and IT operations teams.

A SOC is a proven method to improve threat detection and incident response, reduce the potential for security breaches and help organizations respond appropriately in the event of an incident. The SOC team isolates unusual activity on servers, databases, networks, endpoints and applications, identifies and investigates security threats and responds to security incidents as they occur.

SOCs were once considered suitable only for very large organizations. But many small organizations today are building lightweight SOCs, such as hybrid SOCs that rely on a combination of part-time in-house staff and outsourced experts or virtual SOCs that function without physical facilities.

SOC Challenges

SOCs play a critical role in protecting an organization’s assets from cyber threats and ensuring the security and integrity of its networks and systems. However, SOCs can face a variety of challenges in their efforts to detect and respond to potential threats, including:

Alert Overload

Alert overload is a common challenge faced by SOCs. It occurs when the SOC team is inundated with too many security alerts, making it difficult to prioritize and effectively respond to them. This can be caused by a high volume of alerts, a lack of context or proper prioritization, limited visibility, or limited resources. To address the challenge of alert overload, SOC teams may implement strategies such as tuning security tools, implementing a triage process, utilizing automation, and increasing the size of the team.

Visibility Gaps

Visibility gaps refer to areas of an organization’s networks and systems that are not adequately monitored or protected by security tools and processes. These gaps create vulnerabilities that cyber threats can exploit, making it difficult for SOC teams to detect and respond to potential threats.

Visibility gaps may be caused by complex environments, limited resources, shadow IT, or misconfigured systems. To address visibility gaps, SOC teams may implement strategies such as implementing a security information and event management (SIEM) system, conducting regular assessments, implementing additional security controls, educating employees and ensuring that systems are properly configured.

Complex Investigations

Investigating cybersecurity threats can be a challenging task for SOC teams. It requires them to quickly and accurately identify the root cause of the threat and take appropriate action to contain and mitigate it. This can be difficult due to limited visibility, complex environments, a lack of context or limited resources.

To aid in the investigation process, SOC teams may use forensics tools to gather and analyze evidence related to potential security incidents. Common tools include network forensics tools, which allow the team to analyze network traffic and identify the source of a threat and digital forensics tools, which allow the team to examine devices and systems to identify evidence of an incident.

Slow Detection and Response Times

Slow detection and response times are a common challenge faced by security operations centers (SOCs). They can impact the organization’s mean-time-to-detection (MTTD) and mean-time-to-response (MTTR), which measure how long it takes the SOC team to detect and respond to potential security incidents.

A high MTTD and MTTR can have serious consequences for an organization, as it may allow a cybersecurity threat to remain active for an extended period of time, potentially causing significant damage.

What Is DevSecOps?

DevSecOps stands for development, security and operations. It is a new work process that involves integrating security practices into all DevOps processes. The DevSecOps mindset guides all technical experts equal access to security expertise.

DevSecOps moves security practices and enforcement early in the development process. This creates a culture where security is everyone’s responsibility, not just that of the security team.

Building security into every phase of the software delivery life cycle enables continuous integration and high development velocity with fewer security issues and lower compliance costs.

How DevSecOps Improves Security and Quality

Organizations using the DevSecOps model understand that security should not be an afterthought and should be a core part of the software development life cycle (SDLC).

DevSecOps collaboration is more difficult than DevOps because it requires achieving two seemingly contradictory goals simultaneously—expediting the delivery process while spending more time to make sure code is secure and free of bugs.

To implement DevSecOps without compromising product quality, organizations need to create a culture that deals with security-as-code, encouraging developers to consider the security aspects of their projects and automate security tasks. Organizations need to establish ongoing communication and collaboration between IT engineers, software developers and security teams.

How DevSecOps Processes Are Transforming the SOC

Traditionally, SOC processes were completely isolated from the rest of the organization. Developers would build systems, IT Ops run systems, and security protected them. Today, it is understood that merging these three functions into one organization that shares responsibility for security improves security and significantly increases operational efficiency.

SecOps was a second phase, in which operations and security teams became one organization. Security was shifted left, starting from early stages of IT requirements and system design, not at the end of the process.

SecOps had a major impact on organizations implementing DevOps. It paved the way for the third phase—broader collaboration between security, operations, and software development teams, known as DevSecOps. This moves security even further to the left, building security into the system from the first iteration of development.

DevSecOps can operate in parallel to a SOC. Here are some ways SOCs can modernize their processes, even if the SOC itself is a silo:
- Develop a decentralized SOC with DevOps members: Department members familiar with DevOps can help with incident response by gaining insight into IT systems and understanding vulnerabilities and threats to security personnel.
- Collaborate with threat hunters and DevOps teams: Instead of isolating threats and reporting them to management, threat hunters can communicate directly with development or operations teams to address key security vulnerabilities.
- Create a Center of Excellence: SOCs can work with development and operations teams to adopt security best practices and spread these positive results throughout the organization to promote DevSecOps practices.
- Allow the SOC to provide advice and guidance: Everyone involved in security should have easy access to the SOC and be able to work with the organization’s top security experts.
Conclusion

In conclusion, while DevSecOps can significantly impact how SOCs operate, it is unlikely to completely replace the SOC. DevSecOps emphasizes the integration of security practices and tools into the development process from the beginning, which can help to prevent security incidents from occurring in the first place. However, it is still important for organizations to have a dedicated team in place to monitor for and respond to potential security incidents.

The SOC will continue to play a critical role in protecting an organization’s assets from cybersecurity threats and ensuring the security and integrity of its networks and systems. By adopting DevSecOps practices, the SOC can improve the security and quality of the organization’s software applications, reduce the risk of security incidents and improve the efficiency of its operations. However, the SOC will remain a vital part of the organization’s overall security posture and will continue to evolve and adapt to new challenges as they arise.
January 5, 2023
How SASE Can Ease DevSecOps Adoption
DevSecOps is a software development methodology that merges development (Dev), security (Sec) and operations (Ops) into one team that integrates security throughout the entire software development life cycle (SDLC). The goal is to deliver high-quality applications quickly and securely.

The traditional software development life cycle introduces security in the late phases of the SDLC. However, this approach cannot protect against sophisticated cybersecurity attacks. Today’s cybersecurity landscape requires shorter, frequent iterations to quickly patch and fix security issues. DevSecOps integrates security into the continuous integration and continuous delivery (CI/CD) pipeline to ensure teams can address pressing security issues at DevOps speed.

Many organizations are enthusiastically adopting DevSecOps but, in the process, discover they don’t have the necessary infrastructure. DevSecOps requires smooth global collaboration between teams and requires that security controls are built into the IT environment. This is where SASE comes in.

What is Secure Access Service Edge (SASE)?

Secure access service edge (SASE) is a network security model that provides network connectivity with security based on identity, real-time security context and corporate security policies. It is aligned with the zero-trust security paradigm, ensuring that connections are denied by default unless a verified identity has permission to access a specific application, service or edge location.

SASE unifies networking and security functions into one fully integrated service delivered in the cloud. SASE includes several technologies: software-defined wide area networking (SD-WAN), secure web gateway (SWG), cloud access security broker (CASB), next-generation firewall (NGFW) and zero-trust network access (ZTNA).

A key benefit of SASE is enhanced network security. SASE services enhance network security with a granular approach to network protection, detecting and blocking network attacks such as distributed denial of service (DDoS) attacks, man-in-the-middle (MitM) attacks, phishing, email spoofing and malware with deep security scans.

Additional benefits of SASE include:
- Lower cost compared to traditional networks because SASE includes fewer on-premises hardware components and features previously purchased from multiple vendors.
- Easier maintenance because it provides one pane of glass that allows IT teams to manage all applications and users wherever they are.
Components of SASE

Cloud-access Security Broker (CASB)

CASB acts as a bridge between users/devices and cloud applications. It allows organizations to apply security policies, two-factor authentication and single sign-on to all cloud applications, preventing unauthorized devices and individuals from accessing sensitive assets and denying access by default.

Zero-Trust Network Access (ZTNA)

ZTNA ensures that users or devices have explicit permission to access applications or resources. It is a critical component of a zero-trust security architecture, ensuring that internal, private applications are hidden from users who should not have access to them. It also enables secure remote access through layered authentication. ZTNA provides flexible security to meet modern security requirements.

Software-Defined Wide-Area Networking (SD-WAN)

SD-WAN is a connectivity architecture that separates network hardware from the physical control layer. It improves network performance by enhancing and simplifying WAN performance and management. SD-WAN supports modern, cloud-based applications and services while reducing connectivity costs. Combining SD-WAN with advanced security features provides a foundation for enterprises to transition to SASE.

Secure Web Gateways (SWG)

SWG protects online devices from malware infection, enforces corporate security policies and filters unwanted websites in user-initiated internet traffic. SWG provides URL filtering, application control, DLP, antivirus, sandboxing and SSL inspection. All these capabilities protect users from harmful websites and enforce security policies while ensuring full web access and promoting productivity.

Firewall-as-a-Service (FWaaS)

FWaaS is a firewall solution delivered as a cloud-based service. It provides hyperscale next-generation firewall (NGFW) features, including web filtering, advanced threat protection (ATP), intrusion prevention systems (IPS) and domain name system (DNS) security. By integrating FWaaS into the SASE platform, organizations can provide a wide range of cybersecurity capabilities at the edge.

Centralized and Unified Management

The modern SASE platform enables IT administrators to manage SD-WAN, SWG, CASB, FWaaS and ZTNA with centralized, unified management across networks and environments. This allows IT team members to focus on more pressing areas and improves the user experience for the organization’s mixed workforce.

How SASE Will Impact DevSecOps and Security in Organizations

SASE can help secure internal interactions and applications. As a result, the burden on DevSecOps teams is reduced. DevOps teams can use zero-trust network access (ZTNA) to further secure the applications running on SD-WAN. These technologies keep all interactions between endpoints and applications secure.

The SASE model can also help protect mission-critical applications and sensitive data that cannot run on the public internet. To protect these assets, SASE obfuscates traffic, restricts access with a zero-trust architecture, and secures all network entry points with NGFW. It continuously evaluates application traffic for security threats.

Facilitating Collaboration

DevOps teams are focused on time-to-market and are constantly working to accelerate the CI/CD pipeline. They need to collaborate remotely over a reliable and secure connection. DevOps teams are also working to reduce their reliance on network and security teams. The SASE model helps address these problems.

SASE helps reduce collaboration issues by unifying WAN and network security. SASE solutions provide optimized performance and strong security, so DevOps teams don’t depend on infrastructure staff to provision resources. It gives teams full control over operations without compromising performance or security.

Providing Built-In Security

SASE offers the basic network security features required to secure a DevOps project. This allows teams to integrate different security mechanisms into their networking stack, with all security services sharing an integration context. This plugs the gaps in traditional security architecture often exploited by attackers and protects applications from threats.

Improving Incident Response

SASE can immediately block various attack vectors with security controls embedded in the network fabric, supporting the incident response team’s efforts. SASE increases visibility into behavioral anomalies and security incidents in a hybrid environment.

Integrating SASE solutions into a security information and event management (SIEM) system allows incident responders to gain greater visibility into traffic anomalies and the automated security actions taken by the SASE tools. SASE features like NGFW, SWG, IPS and anti-malware might already contain or eliminate many incidents.

Providing More Reliable Infrastructure

DevOps teams need fast, reliable application performance. SASE offers integrated load balancing and failover capabilities that can significantly improve the network’s overall performance.

The SASE architecture can connect all the edge devices, remote users, data centers and cloud resources to a secure, self-healing, fully optimized global network. If a circuit fails or the path becomes congested, the fabric can automatically switch to an alternate path.

Conclusion

In this article, I introduced DevSecOps and showed how SASE, a modern platform that provides fast network connectivity and security at the edge, can support its adoption. DevOps teams can use SASE security components to secure applications across on-premises data centers and clouds. SASE can encrypt and inspect traffic to protect it from threats, ensuring that workloads, users, and development systems are secure by default.

With SASE, DevSecOps teams have the infrastructure they need to secure the environment and can focus on integrating security tests and remediations into the development life cycle.
December 19, 2022
Prioritizing Product Security With DevSecOps

Building software with strong security can no longer be an afterthought for organizations. The need for a reliable cybersecurity posture has proven vital amid the constant attacks we’re seeing across industries, all over the world. Product-specific security is top of mind for most companies, and a successful product security practice requires integrating with the ethos of the engineering team—DevSecOps. Consider a three-fold strategy, which has proven successful again and again in the industry.

It consists of first creating a culture of security, with all stakeholders understanding the priorities, strategies, and business value. Second, teams must integrate security with the software development life cycle (SDLC). It’s not enough to shift left–organizations must shift their thinking from shift left to shift everywhere. And lastly, monitoring product systems at all times is non-negotiable. In a 24/7/365 world, there must be teams to watch over security 24/7/365. Part of the engineering deliverable becomes providing data to these teams so that they can have all eyes on the products, always.

A Successful Practice Starts With the Culture

In building a strong culture, the goal is to make the entire engineering team a part of the mission. This includes putting a product security team in place to support engineering needs as well as providing continuous education with resources available for addressing any eventuality.

While every organization has its own unique needs, considerations and approaches to creating a product security team, these five roles are highly recommended:

1. Technical Product Manager (TPM): Responsible for driving security priorities in planning
2. Security Architect: Sits on the Architecture Review Board and ensures architecture and design have security processes incorporated
3. AppSec Engineer: Responsible for implementing the security development life cycle
4. Adversarial Engineer: Hammers on the attack surfaces to identify weaknesses
5. Security Champions: Engineers from each Scrum team with an interest in supporting their teams with security fundamentals; they are instrumental in scaling out the overall product security effort

Creating and executing an engaging security education program is also pivotal to winning over the hearts and minds of employees. Consider initiatives such as in-depth security boot camps, vulnerability-of-the-month presentations, capture-the-flag (CTF) contests and security consultation programs.

Integrating Security Into the SDLC

From a high level, all SDLCs consist of planning, development and release, and each phase should have its own set of security controls.

Planning: The product security TPM is responsible for working with the product management team to determine security priorities–derived from sources like risk reduction, executive priorities, customer requests, security findings and regulatory requirements. Determining what is most important is key.

Development: Much of the heavy product security lifting comes during the development phase, which includes implementing threat modeling, security baselines and automated scanning.

Threat modeling: The process of identifying potential threats in a system. Once identified, the threat modeling team can create mitigations, and results are integrated into penetration testing to verify that the threats did not make it into implementation. It’s most efficient to test models during the architecture phase before coding begins to avoid rework and Band-Aids. For example, a company may have a policy disallowing access to port 22 from the Internet. Threat modeling automation can detect violations in the design and notify the owning team asking them to close the port. Tools that support this use case include IriusRisk and ThreatModeler, as well as Microsoft Threat Modeling Tool, which is a free option but does not include automation.

Security Baselines: Teams should create secured images that are fully patched, meet security policies and have mandatory security agents preinstalled. Doing this for both OS images and containers allows developers to get a level of security for “free” and avoid ongoing security reviews. Baselines should automatically update and flow into CI/CD systems.

Automated scanning: To keep up with Agile processes, scanning should be automated and have a low number of false positives. In fact, it is better to report on fewer issues than kill credibility with a lot of noise. Continuous tuning will increase the fidelity rule sets and helpful tools include static application security testing (SAST), software composition analysis (SCA), and dynamic application security testing (DAST). Automation is critical to securing applications that use a CI/CD development process and providing security right at the code push is invaluable–developers get immediate feedback, not a ticket weeks later when they likely have forgotten important context. Integrating these tools into build pipelines is a solved problem.

For example, the below YAML demonstrates automating source scans for embedded secrets (e.g., passwords and keys).

sast:secrets-detection:
extends: .sast:secrets-detection
stage: deployment:development

Release: When teams reach the release phase, adversarial testing becomes an important component. Penetration testing can be in-house, outsourced or both. An internal red team will have a better understanding of the technology and, therefore, have a broader scope than external security partners. For example, they test across product boundaries, test processes and people and test live production systems. For a mature product, consider a bug bounty program. This will invite white hat hackers to find weaknesses in exchange for cash. But “mature products” is essential; otherwise, the number of payouts will become overwhelming.

24/7 Monitoring

As mentioned earlier, 24/7 monitoring is key, especially for any cloud-based technology. A dedicated security operations center (SOC) can help, scrutinizing for threats against the company, employees and customers. The SOC’s responsibilities are much broader than those of a product security team, and they allow product security folks to sleep well at night. Security teams should configure systems, load balancers, public cloud platforms and networks to feed data directly into the security information and event management (SIEM) system. The SOC can then respond to custom automated alerts that identify any data anomalies that are being streamed to them.

As products–and technology overall–become more advanced, the way organizations secure them must do so as well. The perfect security approach varies from business to business, but empowering IT, engineering and security teams is a beneficial first step to identifying, optimizing and integrating security for both employees and customers.

December 14, 2022
How Devs Can Improve Open Source Security in the Enterprise

Modern applications are dynamic. They’re distributed and they’re often born in the cloud. These applications can be developed on the fly, spun up and scaled quickly to meet evolving user and market demands—enabling a level of business agility that allows users to make quick, informed decisions in real-time and take advantage of opportunities as they arise.

Enabling this development velocity are tens of thousands of open source libraries–pieces of code that developers can include in their applications to perform a specific function without having to code it from scratch. Open source libraries prevent developers from having to reinvent the wheel and allow them to focus on their differentiated business logic. While efficient and a major time saver, open source software may be the biggest single threat to software supply chains today. Developers simply have too much faith in the integrity of free, open source code that they casually include and distribute with their applications.

Despite the operational benefits, the pressure to develop quickly shouldn’t expose the organization to increased security risks. Development teams need to rethink how they use open source software and take steps to ensure they meet the same security standards as other enterprise applications.

The Open Source Security Issue

The problem is that most open source projects are maintained by a small number of developers that contribute their time and expertise to build software components that can be reused by the community at large. However, these developers are volunteers who aren’t being paid for their time and effort, nor are they under the same pressure as enterprise developers to ensure there are no vulnerabilities in their code. They may also lack the level of enterprise security expertise necessary to protect applications from increasingly sophisticated attacks. Some may even be hostile to efforts to better secure their code if it means slowing performance or changing the user experience.

The result is that insecure code is increasingly making its way into enterprise applications that use these open source libraries. In fact, the Log4j vulnerability last year was due to a vulnerability in an open source Java logging library. Recognizing the national security importance of open source software, the Biden administration recently issued an executive order and met with cybersecurity professionals to better safeguard the federal government’s computer systems. The resulting recommendations included policies that would help prevent security vulnerabilities in open source packages, improve the process for identifying and fixing defects and reduce time to remediation for distributing and implementing fixes.

It’s imperative that the private sector take notice and make more of an industry-wide effort to secure open source software that makes up businesses’ most critical applications today.

Three Steps for Better Open Source Security in the Enterprise

The bottom line is that enterprises themselves need to take more responsibility for securing enterprise applications—especially as these applications rely more on open source libraries. They need to take a more proactive approach that spans the entire software life cycle, embeds security tools directly into development platforms and provides complete transparency into what makes up their most critical applications.

Here are three things organizations can do to make sure their open source software is secure:

1. Continuously conduct end-to-end application testing

Modern applications are constantly evolving—making it more imperative than ever to continually test for vulnerabilities throughout the entire software life cycle. Starting with the planning stage, security should be embedded throughout the process—providing developers with a solid framework for building secure code before it goes through testing. Once pushed, application security testing should continue as an automatic, built-in step when pushing code to production. DevOps and security teams should work together to ensure security is no longer an afterthought to feature development.

2. Embed enterprise security capabilities directly in development platforms

Forcing developers to take an extra step to ensure secure code when they’re already under pressure to push code quickly is a recipe for failure. Security teams must make it as easy as possible by integrating security controls directly into existing development processes. Standardizing security testing and controls during development makes it more likely policies are recognized, understood and followed.

3. Ensure transparency in every snippet of code you use

Complexity is the enemy of good application security. DevOps teams need to know exactly what makes up their applications—including open source libraries and their dependencies. The federal government is pushing the open source community to standardize a software bill of materials (SBOM). Similar to regulations that require hardware manufacturers to know where every part is sourced, this would force both open source developers and enterprise developers to take more responsibility for the code they include from other sources. That way, if a vulnerability is discovered in a library, enterprises could easily determine if they are at risk and take appropriate action to fully mitigate the issue as quickly as possible.

It’s Time to Take Greater Responsibility

Open source software enables the kind of development agility that makes businesses thrive, but open source also greatly expands enterprise threat surfaces—leaving many organizations at risk of a breach. Organizations need to take greater responsibility for the security posture of the open source libraries they use to speed application development. This requires end-to-end application testing throughout the entire software development life cycle; embedded security tools and controls in development platforms and processes and complete transparency into the open source software that makes up critical enterprise applications. This proactive approach will ensure that vulnerabilities such as Log4j are identified and patched quickly before threat actors are able to exploit them and compromise applications.

December 8, 2022
What the Convergence of Observability and Security Means for Devs

There is a scene in the movie Apollo 13 when the mission control flight director asks why the carbon dioxide scrubber in the command module was a different shape than the one used in the lunar module (and therefore incompatible). The engineer simply replied, “This just isn’t a contingency we’ve even remotely looked at.”

A similar scenario plays out at many organizations when they examine security and development practices. When it’s time for code to go into production, every developer hopes their code will run as planned–smoothly and error-free. Unfortunately, something will be missed, performance could degrade or new, unanticipated problems can emerge after an application is deployed to production.

Developers fear the “unknown unknowns.” And it keeps them up at night.

When an “unknown unknown” problem occurs, it takes time for teams to do the forensics to identify the problem. It can take days or even weeks for teams to complete that initial investigation. If a mission-critical application is offline for a significant period of time due to a forensics investigation, then it can negatively affect your customer’s experience and, ultimately, your organization’s bottom line.

The “unknown unknowns” problem is another challenge facing developers in today’s unpredictable macro environment. That includes the deluge of data, increasing cyberthreats, an increasingly distributed infrastructure and a remote and hybrid workforce as well as a mix of modern cloud-native and monolithic apps.

To help developers build for the future and address security concerns, it is imperative they rethink the way they are collecting, operationalizing and storing different types of data from a variety of sources.

Security and Observability: Better Together

Today, security and observability have recently begun to overlap, driven by the growing need for organizations to better understand the activity inside their environments. Many forward-thinking organizations are operationalizing the massive amounts of log and event data currently being generated to understand and assess issues in their infrastructure and apps and using these actionable insights to optimize workload, app resource availability, security and uptime.

So how can developers take advantage of the security and observability convergence trend happening right now?

Currently, it’s common for developers to have two agents as part of their tech stack. One agent for observability, which is collecting data such as logs and events to get relevant insights into the health and performance of their application in real-time. The other agent is for security to collect data in their devtest, integration and production environments.

Since these two agents often collect the same data, there is an opportunity to consolidate it into a single location, such as a unified security platform with a single agent, where this data can be overlaid with time series analytics to deliver relevant insights to users. Using this approach of having both security and non-security data in one place will significantly speed up the process of getting these valuable insights into the developer’s hands.

In addition to getting insights faster, another benefit of having this data in a single location is the ability to access historical data. Giving developers the ability to store and manage data for long periods of time allows them to get insights from this historical data, so they can better understand alerts, incidents and adversaries. This can help them correlate in terms of understanding the risk to an application, such as potential “unknown unknown” threats, which they can proactively address before it causes any damage.

Adopting a converged security and observability approach is the most mature step that organizations can take to help developers deliver the best outcomes and best experiences for their customers and users. As more organizations rely on the cloud and the speed of business rapidly increases, developers must transform their view of the health, performance and security of applications and infrastructure. Giving developers this perspective will dramatically help them take rapid action against an adverse event before it impacts their company’s bottom line.

December 7, 2022
Survey Surfaces Raft of DevSecOps Cultural and Technical Challenges

A global survey of 606 IT, security, application development and DevOps decision-makers found that the biggest barrier to adoption of DevSecOps best practices is cultural rather than technical. However, the survey, which polled organizations with more than 500 employees and was conducted by Progress, also found only 16% of respondents planned to prioritize addressing those cultural issues in the next 12 to 18 months.

A full 71% of respondents cited culture as the biggest barrier to DevSecOps progress, with only 30% expressing confidence in the current level of collaboration between security and application development teams currently being achieved. In contrast, 46% of respondents were not particularly confident while nearly a quarter (24%) were not at all confident.

Nevertheless, well over half of respondents (57%) said security threats are the number-one technology factor driving the evolution of DevSecOps, even though just over half (51%) admitted they were only somewhat familiar with how security fit into a DevSecOps workflow.

Overall, 86%of respondents said they are experiencing security challenges that include prioritizing externally facing applications over internal applications (47%), securing different types of workloads that were using different development and delivery methodologies (46%), meeting delivery deadlines (45%) and meeting audit requirements specified by the security team (39%). Just over three quarters (76%) recognized they could be more strategic in managing DevSecOps.

The top three initiatives needed to support a shift to a more strategic DevSecOps approach identified are more investment in continuous learning for developers and engineers (61%), upskilling of developers and engineers to move into site reliability engineering (SRE) roles (60%) and improved communication between developers, security and operations (60%).

Survey respondents also identified a need to define a clear set of policies and procedures (66%), define the role and responsibilities of staff across teams (62%), create a continuous feedback loop (49%) and automate recurring security tasks (41%).
Despite that level of awareness, however, only 40% said they believed implementing security training and upskilling efforts across multiple stakeholders was very important when implementing DevSecOps.

Prashanth Nanjundappa, vice president of product management for Progress, said given all the cultural and technical challenges organizations face, it’s apparent that both a top-down and bottom-up approach to implementing DevSecOps best practices is required. Attempting to shift responsibility left toward application development teams is not going to suffice on its own, he noted.

The survey also suggested that many organizations are trying to address application security issues as they modernize their application portfolio. A total of 59% said they struggled to attain buy-in/funding for refactoring efforts that didn’t provide new user capabilities. However, only 39% said they had adopted a comprehensive modernization approach based on cloud-native architecture principles, while another 22% felt they lacked one entirely. Just under a quarter (24%) said their approach to modernization is to largely rip-and-replace applications.

The top business factor driving the adoption of DevSecOps was a focus on business agility enabled by fast and frequent delivery of application capabilities (59%). Just under half (45%) said it had taken six to 12 months to achieve a return on DevSecOps investments, while 31% said it had taken longer than a year. However, only half (50%) of respondents were familiar and interested in both infrastructure and policy-as-code.

There is no doubt that the DevSecOps journey ahead will be long and arduous. However, there are also a wide range of small process changes that could have a massive impact in terms of improving application security in the short term. The challenge is to quickly identify those opportunities while at the same time employing a more systematic approach that ultimately makes it a lot simpler to implement a set of DevSecOps best practices consistently.

December 5, 2022
Culture a Stumbling Block to DevOps, DevSecOps

Organizations are struggling to improve DevSecOps practices as they confront a lack of cultural alignment and investment, according to a global Progress survey of more than 600 IT, security, application development and DevOps decision-makers.

Many companies are behind in achieving their DevOps and DevSecOps goals, with 73% of organizations saying they could be doing more.

More than three-quarters (76%) of respondents acknowledged they need to be more strategic about how they manage DevSecOps, and 17% said they still consider themselves at an exploratory and proof-of-concept stage.

Prashanth Nanjundappa, vice president of product management at Progress, said the most surprising finding was the evident contradiction between what organizations think is very important and their actual alignment, commitment or investment.

“While security is the number-one driver behind most DevOps and DevSecOps implementations, just 30% said they felt confident in the level of collaboration between security and development,” he added.

Meanwhile, 86% of respondents are experiencing challenges in their current approaches to security and 51% admitted that they don’t fully understand how security fits into DevSecOps.

Nanjundappa pointed out that company culture is, in fact, biggest barrier to DevOps and DevSecOps success.

“We found 71% of respondents agreed that culture is the biggest barrier to DevSecOps progress, yet only 16% were prioritizing culture as an area to optimize in the next 12 to 18 months,” he explained.

The study revealed the top business factors driving the adoption and evolution of DevOps inside their organizations included a focus on agility as well as reducing the business risk of quality, security and downtime or performance issues.

Organizations also recognized the need to implement DevOps to support a cloud mandate or their move to the cloud.

In addition, concerns about public cloud workloads, increasing regulatory requirements and concerns about financial impacts are driving how security around DevOps is approached.

“Organizations are juggling lots of priorities in how they manage security with key focus areas for security being digital marketing efforts, employee apps and customer-facing apps,” Nanjundappa said.

Challenges with security include prioritizing the development of external-facing capabilities over internal apps, the ability to secure different workloads using different development and delivery methods, meeting delivery deadlines and difficulties meeting audit requirements.

“Through the survey, we have seen some of the differences that stand out between organizations that have achieved higher maturity versus others,” he noted.

Some are related to cultural aspects and bring to the fore a focus on business agility through fast and frequent delivery of application capabilities, as well as using DevOps to better manage distributed and/or remote work environments.

Nanjundappa said among the best practices to ensure fruitful collaboration are stakeholder sponsorship on leadership for tools and outcomes aligned with the strategic direction of organizational goals.

“Let teams innovate at the grassroots level with regard to tools and processes to accomplish expected outcomes,” he explained. “Identify teams which have seen success, celebrate those successes and implement those processes across other teams in an iterative model.”

As organizations head into 2023 with a tight IT labor market persisting, Nanjundappa pointed out a key concern will be to find the talent they need to make these DevSecOps initiatives a reality.

“While it is ideal to hire pre-trained talent which fits their organizational needs, it will either be expensive or sometimes close to impossible for multiple reasons,” he said.

He recommended using a multi-pronged approach to bridging talent gap, which includes an on-ramp for hiring experienced key talent and reskilling through cross-pollination of experiences from different teams, including security, dev and ops.

Nanjundappa also advised upskilling existing teams with modern technologies, replacing legacy platforms and tech with cloud and cloud-native technologies and augmenting that with the right level of tools and processes, including policy-as-code and CI/CD.

November 21, 2022
5 Tips for Securing DevOps: What You Wish You Knew Sooner

Foundations and frameworks, concrete and steel—not exciting. But that’s the foundation and framing of pretty much every modern building. Everything else that is part of a building–flooring, wiring, lighting, room placement and so on—is made possible by the foundation and the framework. If you want DevOps to succeed in your organization, you have to start by building a solid foundation and a framework, including security. What’s below is a suggested approach to the concrete and steel of DevOps.

Three Foundational Needs

1. Leadership and Governance
Someone has to make the decisions, be responsible for leading the team(s), give direction and provide operational governance. Securing DevOps is not just about compliance with a set of security concepts; it’s also about setting the right tone for the workplace. Leadership and governance are key enablers of development success.

The pressure to deploy software faster and more often is real—but so are the security, regulatory and many other concerns around automation that may uncover bugs or defects in software before it gets pushed to production. In an environment where there’s pressure to release code faster, how does one balance these competing priorities? What’s more important: Speed or quality? This tension between speed and quality remains one of the main challenges faced by organizations adopting DevOps practices today.

Organizational leadership and governance regarding people and data must be in place to keep people working on the right things, keep up morale, provide direction about project prioritization and budget the right tools for getting the job done.

An important subcategory of governance is data classification. Where does the data reside? Over which channels does it flow? What kind of data is it? Classifying the data has long-term implications for resource procurement such as what storage to use and if it needs to be encrypted, how stringent access control for the environments needs to be and interoperability of the various technologies.

2. Regulatory Compliance
It wasn’t too long ago that if a business remained only national, then there weren’t necessarily many regulatory requirements. Presently, if a business has a website (and who doesn’t?), then international and cross-border data transfer is a given unless one takes the course of geo-restriction, which in itself can be a major undertaking with repercussions.

Determine regulatory needs. From where do people or other services access the data? What cross-border transfer is involved? To paraphrase the late 1960s-1980s public service announcement, “It’s 10:00 p.m. – do you know where your data is?” Design and implement accordingly.

3. Risk Management
One cornerstone of technology management is that it’s all about risk. If there’s a serious incident such as data intrusion or theft, what will the cost be to the organization and was the company part of the problem (e.g., negligence)?

What are the technical vulnerabilities, threats and risks presented by the product or service? What kinds of testing (e.g., regression, penetration, vulnerability, CTI) would it take to assess and address the risks? What does the patch cadence look like?

On the personnel side, what are the risks of key players leaving? What’s the morale of the team regarding aspects such as culture and pay? What’s being done to address those risks? Included are third-party, contractual, and privacy risks (remember data classification above?).

NPM packages are a growing trend as an avenue of exploitation; uptime is a common requirement for meeting obligations, and privacy is considered by many to be more than a privilege but a human right, and not something to take lightly.

Two Framing Activities

The foundation activities undergird the entire structure of DevOps, but also consider what shapes the structure.

1. Software Development Life Cycle (SDLC)
The SDLC is vital. Without it, where do all personnel (team, contractors, consultants) know how to proceed with designing and implementing the product? What model is used, and who’s responsible for what? It’s all here in the SDLC. Of course, things like references for API architecture specifics and corollary application documentation would make one feel like wandering in the Library of Congress (and make developers want to burn it down like the ancient Egyptian Library of Alexandria!).

Speaking of APIs: Due to the enormous rise of API use in all industries, including health care and retail, any use of APIs must be part of the SDLC.

Not only are APIs on the rise for public use and interaction, but microservices use within an org has increased drastically. APIs are necessary internally and externally for businesses to reach, maintain and accelerate the speed of innovation, so including them as critical resources is crucial. The average API usage per company increased by 221%, so attending to that ecosystem by ensuring proper activities, especially security, are included is needed for developers.

The SDLC is there to make workflow and production consistent (and concomitantly easier) by codifying what needs to be done for both company and customer, not to make work more difficult by presenting nauseating tedium. Like any corporate policy, it needs to remain useful, while not watered down.

Here are a few specific aspects to include:

● Threat modeling in some form needs to be included. It doesn’t have to be a magnanimous effort, but the realities of threats will play a major part in development.
● Testing. Regression, stress, pentest, security – these and others will help guide what kind of testing environment one will need and lead to any need to increase items such as capacity and scalability.
● Secure coding. If it’s being done, take steps to improve. If it’s not being done, just get started. It’s always hard to go back and fix insecure code, but it’s a necessity due to the many risks and regulations involved in providing software to the public.

2. Training
Training is required because businesses have to adapt as technological changes create new opportunities that lead to continuously changing customer demands.

Training is everywhere! There’s no one right place or right approach – just get training and change as needed (specifics should be handed down by leadership).

On a strict and lowball budget? One option is OWASP membership (which costs $50 per person per year) and includes several types of AppSec and DevSecOps training. That small investment can help raise the level of clean and secure coding, threat and security consciousness and professional reputation.

Setting the Course and Always in Motion

An issue with setting any course in business is that it’s semi-permanent. A DevOps model put in place becomes part of the foundation, which can make one reticent to commit. The only way to prove the chosen methods is to set them in stone and do them consistently for a long time. Aspects of the model may change over time, but once that foundation is put in place, it takes an enormous amount of work, time and money to change it. The change wouldn’t be a remodel, but a reconstruction, so the model takes proper consideration at the outset to chart the right course.

While DevOps needs a solid foundation, it’s an always-in-motion model. There are new technologies, new people, business changes, customer demands and societal and cultural shifts. These concepts can be included in calculations, but what those changes will be is incalculable. Hire and train the right people and the necessary steps and adjustments will be possible.

November 16, 2022
Codenotary Automates SBOM Creation

Codenotary today launched a tool that enables an application to automatically generate a software bill of materials (SBOM) by adding a single line to its source code.

Codenotary CEO Moshe Bar said TrueSBOM makes it possible to self-report the components used to construct applications to any organization that uses them for the first time. In contrast, existing SBOMs only provide a snapshot of the components of an application at the time it was initially created, he added.

IT organizations are being asked to trust application providers that all the modules specified in the SBOM are the only components being used. Codenotary is making a case for an approach that enables the organization consuming that software to spin up an SBOM in real-time on demand.

From a DevSecOps perspective, adding a single line of code to the application to enable TrueSBOM should also eliminate the need to create and maintain separate text files to generate an SBOM.

Awareness of the need for SBOMs has skyrocketed 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.

That approach also makes it a lot simpler for organizations to accurately pinpoint where components are actually running any time a new zero-day vulnerability is discovered, added Bar.

Priced at $1,450 per application stack per year, there are also lower-cost instances of TrueSBOM available for applications based on either a serverless framework or using the portable WebAssembly (Wasm) format.

Most internal DevOps teams already have a good handle on what software components are being employed with the applications they deploy, said Bar. The issue is that the organizations that use that software can’t easily verify what components are being employed, he added. That’s problematic because an organization may have decided to prohibit deployment of a specific software component because of a known vulnerability. Rather than trust a text file created by the provider of an application, TrueSBOM allows the user of an application to maintain control over their software environment, noted Bar.

It’s not yet clear how most organizations will operationalize SBOMs now that more of them are being created. Ideally, organizations should be able to approve only software that has components that have been verified to be secure. Armed with those insights, over time, it should become simpler to start reducing security technical debt with more secure applications, added Bar.

The challenge, of course, is that the Codenotary solution requires the addition of one line of code to an application. However, as SBOM mandates become more stringent, the number of application providers that are anxious to comply with rules for securing software supply chains should increase. The issue now is finding a way for both the developer and consumer of that software to streamline a verification process that, in its current form, is too cumbersome to effectively manage.

November 14, 2022
Aqua Security Claims Compliance With Biden’s Executive Order

Aqua Security this week claimed it is the first software supply chain security platform provider to meet the attestation requirements as defined by an executive order issued to federal agencies last year by the Biden administration.

A supplementary memo issued by the Biden administration required federal agencies to collect compliance attestation letters for all software they use by September 14, 2023. Those attestation letters need to confirm that the software development environments they employ are secure, that sources of code are trusted and that code vulnerabilities have been remediated, provenance for data and code is being tracked using a software bill of materials (SBOM) and that these processes are being consistently maintained.

Eilon Elhadad, senior director of supply chain security for Aqua Security, said Aqua Security was able to meet those requirements within 100 days of the issuance of that memo. The Aqua Security platform for securing software supply chains is based on a platform it gained with the acquisition late last year of Argon, a provider of a set of tools that provides an agentless approach to integrating with continuous integration/continuous delivery (CI/CD) platforms that maps the development environment. Armed with those insights, it then becomes possible to prioritize and automate the remediation of vulnerabilities based on security best practices and compliance rules, noted Elhadad.

The Argon platform also includes code-tampering detection technology that performs validity checks to make sure the integrity of the build process has not been compromised.

Naturally, there’s plenty of time for other security platform providers to comply with the requirements set forth in Biden’s executive order. However, software development teams are also in a race against time. In the wake of a series of high-profile breaches, it’s become apparent how vulnerable software supply chains really are. Cybercriminals have increased their efforts to compromise developer credentials so they can embed malware in software components and activate them downstream if future application incorporate that component, noted Elhadad.

It’s not clear how closely enterprise IT organizations are tracking the efforts of the U.S. government to secure its software supply chain, but any entity that builds software used by any of those agencies will be impacted. Advocates of DevSecOps best practices within enterprise IT organizations will undoubtedly use the Biden administration’s requirements to define a minimum baseline for securing software supply chains.

In the meantime, a new front has clearly been opened in the cybersecurity war. The more applications are targeted, the greater the impetus for shifting responsibility further left toward application development teams becomes. The challenge is not just scanning the code being written by developers, but also making sure the software build created by development teams has not been compromised by bad actors that have inserted themselves into the process, noted Elhadad.

Given the magnitude of the effort required, it’s not likely that every software supply chain will be secured any time soon. However, the responsibility for securing those software supply chains is weighing more heavily on DevOps teams.

November 11, 2022