devopsy.kinsta.cloud

Tag: Cybersecurity

  • Why Backups and Compliance Go Hand-in-Hand

    Why Backups and Compliance Go Hand-in-Hand

    It’s hard to run a business. Besides the numerous challenges you have to deal with daily, ensuring the security of your business and customer information is essential for operating smoothly. In order to mitigate information security risks that would affect companies and their users, a number of security regulations have been created, including a set of best practices that companies must follow.

    Compliance with these regulations will allow you to:

    ● Reduce security and privacy risks
    ● Strengthen control of key processes
    ● Align cybersecurity requirements with business processes
    ● Better understand cybersecurity goals and how to handle business security challenges
    ● Maintain effective cybersecurity programs
    ● Build customer trust and improve company reputation

    One critical requirement to achieve compliance is backups. Organizations back up information that’s vulnerable to threats like software or hardware failures, cyberattacks or human error. Any one of these problems could potentially lead to data loss, system malfunctions, financial losses and reputational damages. In this post, you’ll learn more about why data backups are an important part of compliance and about the benefits of having a robust backup strategy.

    Why are Backups Important for Compliance?

    Regulations like GDPR, PCI-DSS and HIPAA, along with others, were created to ensure that organizations implement the most reliable methods to secure all types of sensitive data from infrastructure failures and malicious attacks.
    Compliance can’t be achieved unless an organization handles data in a way that adheres to the outlined regulations.

    Certifications like ISO 27001 and SOC 2 are considered the most thorough audits an organization can go through to prove they have taken all the necessary steps to protect business and user data. Unlike the regulations mentioned above, ISO 27001 and SOC 2 aren’t legal requirements, but they’re especially beneficial to SaaS companies, data centers and organizations that deal with sensitive information. They make it very clear that the company takes data security very seriously and considers it a top priority. By properly implementing the data and privacy controls required, you can increase reliability and user trust as well as gain a competitive advantage over other companies.

    To be able to obtain such certifications and comply with regulations and different standards in general, you’ll have to maintain robust, up-to-date backup processes that ensure data is always protected but also available to users—even in cases of unexpected events like natural disasters, cyberattacks, data losses and human error. In other words, to comply with regulations, your backup processes must match your business continuity plan and the data backup tools you are using should be able to handle your backup processes.

    Backups, of course, do more than enhance business continuity, as mentioned above. Although they can’t prevent an attack or a data loss from happening, they’re an integral part of your overall security strategy since they allow you to restore lost or corrupted information, mitigating the consequences of such an event.

    There’s no fixed rule for how frequently you should back up. Still, ideally, to secure valuable information, you should implement a combination of full and partial backups as often as possible. Fortunately, great data backup solutions can efficiently handle this complex but crucial task.

    The Difference Between Backups and Compliance

    Backups and data availability are just one of the many requirements for a company to comply with any regulation. It’s an important part, but it’s not enough on its own. Obtaining a security certification isn’t a quick and easy process that you can decide to do and then finish a month later. It’s a time-consuming process that will require buy-in from every member of your team and will ultimately involve in-depth tests and evaluations of how you secure data.

    Although each certification is slightly different, all of them require a company to implement a wide range of security procedures. For example:

    ● Structure your organization in a way that allows optimal management of your services.
    ● Have a strong disaster recovery plan.
    ● Communicate in detail with users about how your system works, your security policies and your processes.
    ● Perform risk assessments regularly to identify risks, measure their impact and create a plan to address them quickly and effectively.
    ● Continuously monitor your security controls to verify they’re operating as expected.
    ● Make adjustments as needed to stay ahead of the latest security threats.
    ● Control physical access to your devices and prevent unauthorized access to your systems.
    ● Integrate best practice security procedures into your day-to-day workflows.
    ● Optimize system operations to detect vulnerabilities early and deal with security incidents.
    ● Clearly describe how you handle changes in your infrastructure to ensure that they won’t affect your business operations.

    The above is far from an exhaustive list, nor will it guarantee regulatory compliance. There are numerous criteria you need to fulfill. Although compliance might seem a huge undertaking, the benefits surpass the difficulties.

    As the security risks in the technology world are constantly changing and becoming more sophisticated, organizations must be able to deal with them or face the consequences. For businesses that want to protect their customers and themselves, following security standards has become necessary. But security compliance isn’t an easy task, and it’s made more complicated by the fact that all of the vendors you use must also be compliant.

    Having a reliable data backup strategy is a crucial step for compliance with regulations and achieving business continuity. Fortunately, there are top-notch data backup tools that can make this complex process easier. These tools allow you to back up regularly to secure your valuable data, and will often automatically run backups on a schedule of your choosing. If you wish to remain compliant and ensure your data is protected, I highly recommend installing a backup service.

  • Implementing Shift Left Security in the Cloud

    Implementing Shift Left Security in the Cloud

    While ransomware has been the leading concern for enterprise security teams over the few past years, software vulnerabilities are nipping at its heels. The boom in cloud-based apps and services and increased digitization of work have been a boon for hackers, who are taking advantage of developers’ and DevOps teams’ attempts to work faster and smarter to keep up with demand. One estimate says that four out of 10 zero-day attacks carried out in the last decade happened in 2021 alone.

    Many things account for this increase. Developers are stretched and are reusing code, which allows for misconfigurations and vulnerabilities to reappear unexpectedly in different programs, and the use of multiple cloud services fragments security measures and reduces visibility into the code running many enterprise functions. This is why developers and security professionals alike are paying more attention to security throughout the software development life cycle (SDLC), particularly in the early stages.

    Shift Left Security Principles and Challenges

    The zero-day surge has led to an increased interest in shift left practices as a way to make security a priority in the development process. Shift left culture brings security into the equation much earlier in the software life cycle, before the software is deployed, rather than patch bugs after users report them. This preemptive approach helps head off vulnerabilities that can affect an application’s security posture unbeknown to its defenders.

    Shift left principles can also enhance security when developers build applications for cloud platforms—such as Amazon Web Services, Microsoft’s Azure or Google Cloud—where visibility into the proprietary code and security tools of the platform can be limited. In a shift left culture, DevOps embeds least privilege policies as part of the daily work on cloud workloads, to protect network infrastructure and avoid granting excess permissions on those workflows.

    For example, setting up role-based access control (RBAC) on Kubernetes containers enforces a least privilege model on those clusters and avoids excessive permissions that can lead to a breach, while removing admin credentials from continuous integration/continuous delivery (CI/CD) workstations shuts off hackers from using those pipelines as an attack vector.

    Shift left security is a great concept, but runs into hurdles in execution, mainly the internal conflict between development teams who want to move at the speed of business while security staff takes a more cautious approach. This leads to friction, with developers warning about access denials affecting their work and causing deployment delays, while the security analysts worry about data breaches caused by too many users with unchecked admin privileges.

    Working out this friction requires a mindset shift, where DevOps understands that security is part of the development process, and management can trust that developers have security in hand. This also requires tools and training to integrate shift left practices, such as platforms that can bridge the security needs of the CISO (by granting greater visibility into the network infrastructure code, for example) and the agility needs of the DevOps teams (by automating security guardrails and entitlements, for example). The ultimate goal is creating what is known as a DevSecOps model, bringing together development, security and operations into one agile, safe and efficient workflow.

    How to Adopt Shift Left Security on the Cloud

    Four best practices can help:

    ● Gain deep visibility: With enterprises often working in multiple cloud environments—and mixing public and private clouds into hybrid infrastructures—visibility into assets typically suffers, which makes getting a clear view of risk difficult. Being able to discover all identities, permissions, configurations and resources in the environment and all the access paths to specific resources can help build a contextual inventory of cloud assets to better manage them and carry out policy analysis.

    ● Prioritize risk: Risk management is a key practice of any security program, but the flood of alerts from multiple cloud providers and systems can overwhelm security operations centers, which are often short on talent and time. Automation tools can now search and prioritize risks across an entire cloud environment, from development to production, spotting problem combinations and alleviating the workload of sorting manually through alerts across multiple silos, freeing the staff to work on higher-priority mitigation and remediation tasks.

    ● Just-in-time access: Zero-trust architecture has become the standard to aspire for most security defenses, but it is often challenged by the difficulties of managing access privileges. Just-in-Time (JIT) access, granting limited-time revocable rights, is a useful tool for building a zero-trust security architecture and enforcing least privilege policies to maintain it. Technology tools that actively manage and monitor developer access to cloud environments, including a strong audit trail of privileged activity, give security a means to enforce JIT access and zero-trust in turn.

    ● Find and prevent vulnerabilities and misconfigurations: Infrastructure-as-code (IaC) has made software deployment in the cloud (much more agile and efficient with the use of virtual machines, containers, microservices, etc. However, security is often an afterthought both pre- and post-production when standing up cloud infrastructure. Organizations should scan code for security policy violations and other risks in order to mitigate flaws before they reach production and to detect and fix problems in production environments. With feedback and automated guardrails built into development workflows, DevOps and security teams can reduce security risks in their code.

    Like zero-trust, shift left is on its way to becoming a standard practice for cybersecurity assurance. But building a DevSecOps model takes more than good intentions. It requires practices, tools and training to execute that model, and a mindset of partnership across the enterprise and with outside cloud and security partners. Only a group effort will provide the cloud security assurance an agile business needs.

     

  • Palo Alto Networks Buys Cider Security to Lock Down Pipelines

    Palo Alto Networks Buys Cider Security to Lock Down Pipelines

    Palo Alto Networks this week extended its efforts to secure application environments by agreeing to acquire Cider Security, a provider of a platform for securing continuous integration/continuous delivery (CI/CD) platforms, for approximately $195 million in cash.

    The acquisition of Cider Security, scheduled to close this quarter, will extend the reach of the company’s Prisma Cloud platform that was updated last year to include a set of tools for securing infrastructure-as-code (IaC) used to provision IT infrastructure. Palo Alto Networks previously acquired Bridgecrew, which had developed an open source Checkov policy-as-code tool. Last month, Palo Alto Networks added software composition analysis tools to Prisma Cloud, as well.

    Cider Security developed what it described as an operating system for application security. The solution creates a graph that enables DevOps teams to visualize the relationships between all elements that make up a software development environment, including code. It then makes it possible to apply a set of controls to remediate any vulnerabilities and attack paths that might be identified using any number of third-party scanning tools.

    Palo Alto Networks CEO Nikesh Arora told industry analysts the acquisition is an example of the company doubling down on securing software supply chains alongside its existing portfolio of platforms and services for securing production environments.

    It’s not yet clear who is in charge of DevOps platform security, but increasingly there will be some type of central security function that works with application development teams to lock down software supply chains, said Mike Rothman, general manager for Techstrong Research, an arm of the parent company of devopsy.kinsta.cloud. “There’s going to be a central security group focused on securing the pipeline,” he said.

    As Palo Alto Networks continues to extend the reach of Prisma Cloud left, it continues to make a case for centralizing the management of cybersecurity through a portfolio of platforms that can be centrally managed via the cloud. It’s not clear how much organizations are centralizing management of security across their software supply chains and production environments, but Arora noted that interest in consolidating security vendors is high as organizations look to reduce the total cost of cybersecurity.

    In the meantime, organizations of all sizes are looking to employ DevSecOps best practices to better secure software supply chains in the wake of a series of recent high-profile breaches. In addition to scanning code for vulnerabilities, many of those organizations are starting to realize the tools and platforms used to build applications are also vulnerable to cyberattacks. The goal of those attacks is to insert malware that will manifest itself in any number of downstream applications that are eventually deployed in a production environment.

    It’s not yet apparent just how compromised those tools and platforms may be, but it’s clear software consumers are moving toward holding developers more accountable for vulnerabilities. The best-known example of those requirements is an executive order issued by the Biden administration that will require federal agencies to include software bills of materials (SBOMs) that list known vulnerabilities. Many enterprise IT organizations are expected to adopt similar requirements.

    One way or another, however, the tools and platforms that make up a software supply chain, along with the code they produce, are going to be subject to much greater scrutiny than ever before.

  • 5 Tips for Securing DevOps: What You Wish You Knew Sooner

    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.

  • Aqua Security Claims Compliance With Biden’s Executive Order

    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.

  • Standardizing Federal Cybersecurity With DevSecOps

    Standardizing Federal Cybersecurity With DevSecOps

    DevSecOps is having a moment in the federal government. With President Biden’s Executive Order on Improving the Nation’s Cybersecurity and federal agencies’ issuance of DevSecOps best practices based on the Enduring Security Framework, government organizations are shoring up and standardizing their DevSecOps processes to meet today’s cybersecurity challenges head-on.

    Integrating security into the development process is particularly important for federal agencies that have invested significant time, effort and money in creating and running software development factories. These agencies are actively trying to balance security and innovation–and many are succeeding. The United States Air Force’s Kessel Run program is an example of a tightly run and innovative software factory.

    The question is: How can they continue this success as the calls for standardized cybersecurity grow increasingly louder?

    The Delicate Balance Between Security and Innovation

    It’s tough to balance security and innovation and wrap them both in a standardized process. It’s certainly not impossible, as Kessel Run proves. But it does require a high level of rigor to ensure that applications are being developed at speed while taking the necessary time to mitigate and minimize security risks and vulnerabilities. 

    Projects like Kessel Run and others work well in part because they bake security into the development process from the outset. That core tenet of DevSecOps allows teams to integrate and standardize security throughout their development cycles without losing momentum. 

    But, there are challenges to these standardization efforts that are inhibiting DevSecOps practices. 

    First, many government agencies are still working with legacy systems and toolsets rather than the modern technologies that many commercial companies that employ DevSecOps have access to. These technologies can include everything from collaboration platforms, to messaging applications, to underlying platforms that tie all the work being done together. 

    Second, despite the government’s commitment to innovation, old ways of thinking still persist in many pockets of the public sector. Some important people still think, “Why change when email has worked just fine for all these years?” Those people fail to immediately see the value of modernizing their toolsets and practices.

    But outdated technologies and processes won’t help government agencies balance security and innovation–and they won’t work with new cybersecurity policies and mandates. For instance, president Biden’s EO is filled with allusions to ensuring visibility into software development practices and the software supply chain. Doing both requires developers, security managers and operations managers to be on the same page and in constant communication at all levels of the development cycle. 

    Maintaining Situational Awareness Throughout the DevSecOps Process

    Yet even in the most mature DevSecOps environments, this isn’t always possible. Because while DevSecOps is driven by collaboration, that doesn’t mean that developers, security managers, and operations managers always know who’s working on what, or what the status of a particular project is at all times. This is particularly true in a government setting where old processes, technologies, and siloed teams are still present.

    But maintaining the balance between security and innovation is highly dependent on being able to have unfettered situational awareness throughout the development lifecycle. For example, a developer needs to know if a security operations teammate is working on fixing a vulnerability the developer discovered during testing. Likewise, an operations manager needs to know the status of the patch, as that might impact other factors important to the development process, including time to deployment.

    High-level dashboards help all team members quickly ascertain the status of projects in development and are useful in helping individuals understand where things exist in the pipeline. They can provide a quick, at-a-glance take that leaders can use to plan their projects, discover backlogs or potential roadblocks to deployment, and more.

    But even dashboards are not necessarily enough, because stakeholders need to be able to quickly and securely communicate status updates to each other.

    Collecting Communications, Facilitating Collaboration

    The problem is that not all of these individuals will necessarily be using the same tools. Some might be using one messaging service. Others might be holding impromptu video meetings. Others might be posting updates to project management boards. Software development is a living and agile process, and communication is happening all the time through different channels.

    That’s why it’s critical for agencies to pull all of these disparate threads together, especially if they are to properly manage security and maintain compliance with the EO. A single missed communication about a software vulnerability could end up becoming tomorrow’s SUNBURST attack. There must be a way for all DevSecOps stakeholders to interact with each other, regardless of their choice of tools or the channels they’re using.

    This is where the choice of modern toolsets and platforms comes into play. Pulling disparate threads together to facilitate better communication and collaboration requires technologies with the ability to connect various services, automate task management and alerts, and break down any lingering communication silos. It requires an underlying architecture that connects all key stakeholders so they can collaborate and ensure the security of the applications they’re working on. 

    Meeting the Cybersecurity Moment

    Older technologies and practices aren’t up to the moment government agencies are facing. They are unsuitable for today’s software development processes, and will not aid in the quest to stay ahead of today’s cyber threats.

    To meet the moment, government agencies must embrace new ways of communicating and collaborating. They must use the tools that are available to keep innovating even while standardizing according to cybersecurity regulations. They must provide their DevSecOps teams with the ability to work freely yet securely and set them up for success.

  • Federal Agencies Share DevSecOps Guidelines

    Federal Agencies Share DevSecOps Guidelines

    The National Security Agency (NSA), Cybersecurity and Infrastructure Security Agency (CISA), and the Office of the Director of National Intelligence (ODNI) have published a set of DevSecOps best practices based on the Enduring Security Framework (ESF).

    Developed by a public-private cross-sector working group led by NSA and CISA, the ESF framework was created in the wake of the breach of the SolarWinds software supply chain that led to malware being distributed downstream to a number of organizations that relied on the company’s IT management platform.

    The Securing the Software Supply Chain for Developers set of best practices published by NSA, CISA and ODNI takes the ESF a step further. The guidance walks organizations through the processes required to develop secure code, verify third-party components, harden build environments and deliver code.

    The best practices provided are the latest dividend of an executive order issued by the Biden administration that requires every federal agency to review the security of its software supply chains. The expectation is that enterprise IT organizations will conduct similar reviews using the best practices and frameworks defined by the federal agencies that specialize in cybersecurity.

    The challenge, of course, is embedding those best practices within existing DevOps workflows. In theory, more responsibility for cybersecurity is shifting left toward application development teams. However, the level of cybersecurity expertise that exists today among application developers is limited at best. Cybersecurity was an elective in most developers’ training and education programs, so it should come as no surprise that few of them ever attended a cybersecurity class.

    There’s a clear need to improve cybersecurity training for developers, but the real work involves automating cybersecurity processes within the workflows managed by the tools developers employ to write code and the platforms that DevOps teams use to deploy applications, said Mitch Ashley, principal analyst for Techstrong Research, an arm of Techstrong Group that is also the parent company of devopsy.kinsta.cloud. “Security needs to be part of the toolchain, workflows and how the software is designed,” he said.

    Ideally, organizations should appoint a security champion that will work with development teams to consistently implement a set of DevSecOps best practices, added Ashley.

    Of course, the security champion doesn’t eliminate the need for cybersecurity professionals. Rather, it reduces the pressure when there is a chronic shortage of cybersecurity professionals. In the absence of any formal cybersecurity review during the application development process, it’s simply too easy for developers to inadvertently introduce malware into a software component or misconfigure a cloud infrastructure service. In either case, cybercriminals are increasingly finding it easier to compromise software supply chains at multiple points.

    It’s not clear how much the federal government’s guidance might impact the overall state of application security. However, one way or another the level of security scrutiny being applied to how applications are built and delivered is only going to increase in the months ahead. The challenge is finding a way to deliver secure code without necessarily slowing down the rate at which applications are currently being built and deployed.

  • Contrast Security Adds API Support to Security Platform

    Contrast Security Adds API Support to Security Platform

    Contrast Security has fully extended its vulnerability scanning and runtime application self-protection (RASP) platform to now include application programming interfaces (APIs).

    Company CTO Jeff Williams said the Contrast Secure Code Platform embeds agents directly into code to detect vulnerabilities using a combination of integrated static and dynamic application security testing tools. That approach makes it simple to embed vulnerability scanning and exploit prevention capabilities within a DevOps workflow as an application is built and deployed, he noted.

    In contrast, traditional approaches to application security depend on legacy platforms such as web application firewalls (WAFs) that are deployed by cybersecurity teams to protect applications in a way that doesn’t provide the same level of granular control at the API level, said Williams.

    Contrast Security claims the Contrast Secure Code Platform improves scan times by a factor of ten while fixing defects 45 times faster. It also reduces false positive alerts by being 200% more accurate, the company claims.

    As more organizations start to embrace best DevSecOps practices to better secure software supply chains, many of them are trying to achieve that goal without slowing down the rate at which applications are built and deployed. That approach, however, requires giving developers and DevOps teams the tools needed to build and deploy secure applications without requiring a lot of direct intervention on the part of a security operations team.

    In general, there is also now a lot more focus on API security as more organizations build and deploy microservices-based applications that rely on APIs to interconnect discreet components. Those APIs should be built, deployed and secured by DevOps teams before they are deployed just like any other software component, noted Williams. The current process of building applications is at its core, from a security perspective, fundamentally broken, he added.

    Application security, in general, has always been somewhat problematic. Cybersecurity teams tend to fund the tools and platforms they regularly employ. The assumption is that application development teams will invest in the tools they need to build and deploy applications. Alas, application development teams that have limited cybersecurity expertise assume that cybersecurity teams are securing both the underlying infrastructure and the applications deployed on top of it. As a result, application security is frequently underfunded.

    In the wake of a series of high-profile breaches of software supply chains there are now at least more reviews of application security being conducted. Contrast Security is making a case for securing the entire application, including the APIs, it invokes using agent software that is injected into the application at the time it is constructed.

    It’s not clear to what degree application security issues will be addressed using agent software rather than traditional cybersecurity platforms managed by security operations teams. Responsibility for application security is shifting left toward developers and the DevOps teams that support them, but as long as humans write code, mistakes will be made, said Williams

    The issue, of course, is many of the members of those teams are still focused a lot more on writing code and deploying applications than they are on cybersecurity.

  • One Year Out: What Biden’s EO Means for Software Devs

    One Year Out: What Biden’s EO Means for Software Devs

    It has been just over a year since president Biden issued executive order 14028 (EO) to improve the nation’s cybersecurity posture. Despite the Log4j vulnerability and a worldwide increase in ransomware attacks, this EO signaled a major step in improving software security at federal agencies and establishing cybersecurity as a priority for the U.S. government. While the agencies tasked under this EO have made significant gains, it is important for industry to understand just how much progress has been made since its inception and what that progress means to the average producer of software.

    To understand the effects of the EO, it is important to remember that president Biden does not have the authority to order any government agency to purchase specific software, nor does the president have the authority to require any governmental agency to procure specific software. Instead, the EO instructs heads of agencies to perform specific tasks that will ultimately define more stringent cybersecurity requirements to protect government offices. This doesn’t mean the EO solely applies to U.S. government contractors; if your company is anywhere in the software supply chain leading to a U.S. government purchase, then you need to pay attention to the EO and plan accordingly.

    One of the first of those tasks was for the National Institute of Standards and Technology (NIST) to solicit input from the public and private industry surrounding the structure and management of software supply chains. That work resulted in an NIST publication on EO Critical Software in July 2021. That publication helped outline security measures for software use, including applying practices of least privilege, network segmentation and proper configuration. It also helped NIST to frame the Secure Software Development Framework (NIST sp800-218v1.1) (SSDF) published in February, which provides a set of fundamental secure software development practices.

    This guidance, along with the definition of a software bill of materials (SBOM) by NTIA in November and the updated Cyber Security Guidance for Supply Chain Risk Management (NIST sp800-161r1) released in early May now form part of the risk-based framework that OMB instructed agencies to follow.

    What it Means To Be “EO Compliant”

    Before beginning any discussion about EO compliance, it’s important to recognize that until there are contract clauses defined—and those contract clauses are incorporated into contracts—there isn’t anything to comply with. That process is part of the Federal Acquisition Regulation (FAR) and Defense Federal Acquisition Regulation (DFAR) effort, and the proposed clauses haven’t been published yet. Despite this, we do know enough to start preparing for future compliance and creating processes that will allow for EO compliance.

    The first step is to recognize whether your organization is a supplier within a supply chain of a U.S. government agency. In the context of the EO, that would mean any organization who creates, procures or embeds software into a component or assembly that is ultimately bought by a U.S. government agency. This includes open source software, low-code/no-code frameworks and DevSecOps tooling, to name just a few of the scenarios where U.S. government use might not be immediately apparent. 

    With that in mind, any provider of software within a supply chain should be prepared to answer questions about EO compliance if their software can be used in the U.S. government setting. For some, this could mean updating a few processes; for others, it may prompt a much larger set of changes in the development cycle. Those willing to change may be more likely to retain relationships or gain favor with government suppliers.

    How Software Providers Can Be Proactive

    There are three critical steps that can be performed today as part of preparing an organization for future EO compliance requirements. The first thing providers can do is generate a complete SBOM for their software in an NTIA compliance format and be prepared to attest to its accuracy. While it is not yet clear how the U.S. government will expect to receive an SBOM or what attestation format will be required, generating compliant SBOMs is one of the easiest tasks software producers will face as part of a post-EO world.

    Next, providers should baseline existing software development practices with the objective of aligning with the SSDF (NIST sp800-218v1.1). The SSDF defines a set of tasks that NIST views as a minimum requirement to securely create software and manage the software creation process. If the government procurement requirements include an attestation of compliance to the SSDF, then software producers who already know how well-aligned they are to the SSDF will be that much closer to compliance. 

    Lastly, providers must implement controls related to open source governance. While an SBOM helps identify open source use and the SSDF includes tasks related to its use, neither specifically defines how any software producer is expected to govern their use of open source software. Open source software is fundamentally different from commercial software in many ways; the most important differentiator is that it is freely downloadable from the internet. This free access means that creators likely do not know who their consumers are and thus cannot proactively provide updates or security information. Open source governance processes can help to fill that gap.

    Why It is Time to Embrace the EO

    These first steps can help software providers address the initial requirements that have come out of Biden’s EO and those who get a jump on implementation will have a leg up against their competition. Starting now can save providers a major headache in the long run, as federal agencies seek an understanding of how much risk they bear when operating the software you produce. 

    The rapidly changing cybersecurity landscape was a key driver behind Biden’s EO. Threat actors are evolving their tactics to keep pace with improving cybersecurity postures and it is in everyone’s best interest—from the federal government to the private sector—to put an emphasis on security. An important place to start—regardless of where you are in any software supply chain—is by taking the steps necessary to demonstrate that you understand the risks inherent in operating software and are actively working to reduce those risks for your customers.

  • TechStrong Con 2022: Exploring What’s Next in Tech

    TechStrong Con 2022: Exploring What’s Next in Tech

    We have become increasingly reliant on technology and it’s hard to imagine life without all the great tech inventions we use in our daily lives. As technology keeps progressing, more is expected of IT teams, and security is a top priority.

    While we are still trying to get used to the new normal, the IT community continues to shine as a beacon, demonstrating how humans are leveraging technology to overcome the many challenges we face. On June 21, business and tech leaders who are working on transforming the world and moving it forward will come together at TechStrong Con Virtual Summit to celebrate the power of technology, share their stories, provide practical insights and lend valuable advice to help other professionals succeed in their careers. More than a virtual event, it is a community gathering that offers learning, networking and upskilling opportunities. Now in its third year, TechStrong Con continues to serve as a testament to the ways in which technology can improve human existence.

    Things You’ll Learn

    The agenda features a mix of topics including live coding, cloud-native, cybersecurity, digital transformation, observability, DevOps, open source and more. Attendees will have the opportunity to learn from some of the brightest minds in the industry about:

    • Managing the security of APIs
    • Key observability trends for 2022
    • How to accelerate digital transformation
    • Habits that will help improve your security posture
    • The state of the software supply chain post-Log4Shell
    • The distributed cloud
    • The future of data engineering
    • Building a diverse cybersecurity workforce
    • Crypto and NFTs
    • Low code and citizen development
    • The value of feature flags
    • How DevOps must be part of your future to attract the right talent
    • Managing and motivating teams in a hybrid environment

    Meet the Speakers

    The speaker lineup features globally recognized business leaders, DevOps, cybersecurity and IT experts including:

    • Sholmi Ben Haim, co-founder and CEO at JFrog
    • Chenxi Wang, founder and general partner at Rain Capital
    • John Willis, senior director of the global transformation office at Red Hat
    • Caroline Wong, CSO at Cobalt
    • Thomas Krane, principal at Insight Partners
    • Lisa Plaggemier, executive director at National Cyber Security Alliance
    • Tami Mazel Shackar, CEO at Incredibuild
    • Tom Sweet, VP in IT solutions at GM Financials

    Visit the Exhibit Hall

    In addition to the sessions, attendees can visit the virtual exhibit hall to interact with partner sponsors including Chronosphere, ConnectALL, Tidelift and TechStrong Research. The expo hall will be open throughout the event, giving attendees the opportunity to chat with the sponsors and download information at any time.

    Registered attendees will also receive a link to access the virtual environment on-demand. To see the full agenda and to register for free, please visit the TechStrong Con website.