devopsy.kinsta.cloud

Category: DevSecOps

  • How to Secure Fintech Applications and Protect Customer Data

    How to Secure Fintech Applications and Protect Customer Data

    All industries are feeling the pain of preventing rising risks to their applications, private information and customers’ data, and it is not surprising that this is especially true in the financial services sector. In fact, fintech companies on average spent more than $18 million in 2019 battling cybercrime, while other markets’ companies spend an average of $13 million addressing cybersecurity concerns each year.

    While these numbers can be depressing, a recent virtual roundtable we hosted with some of the best AppSec brains in fintech uncovered three steps organizations can take to secure their fintech applications and protect their customer data. The panel included Erick Lee, director of Security at Intuit; Jeremiah Kung, first vice president and global head of digital cybersecurity at East West Bank; and Karthik Rangarajan, security lead at Robinhood.

    The panel discussed AppSec trends, best practices for what is working in their organizations and recommendations for security leader peers who are tasked with addressing application security at their organizations. The group agreed that there’s a lot of creative thinking and exciting work happening around AppSec, and that includes across all of DevOps and engineering, not just those charged with application security. These notions can’t help but leave one feeling optimistic.

    While the spirited discussion covered a variety of topics and trends, here are the three high-level recommendations organizations should follow to best secure their fintech applications.

            1. Make sure AppSec teams are hiring software engineers. The panelists agreed that security and engineering functions should not operate as separate entities. One participant described why he hires software engineers instead of security engineers. He explained that software engineers know how to create fixes and operate at scale, which is critical for his organization, which manages 1.5 million requests per second. Since many organizations do not have the resources to hire a security engineer, particularly smaller and growing groups, it is especially important to build security into the engineering team.Organizations tend to discover scalable methods of solving problems and accelerating the development process when engineers are engaged with security. Take for example a security concern that delayed an application release. The panelists agreed that unless the issue is a show stopper, security should not delay a release, unless of course there is a compliance concern or potential violation. They recommended for developers do their thing, and let security work hard and try to keep up.

              The panelists explained this is because companies need to keep pace and release products and triage at scale. This is especially true in the fintech space, where winning business is about application features and capabilities. As an example, one panelist illustrated how his company’s focus is trying to ensure developers have paved roads so they can get “speed to benefit to customers.”

              To make this happen, his company deployed tools for automation, such as solutions that scan GitHub code for potential issues. They are also leveraging automation to monitor for security problems all through production. The punch line for them is to make security complementary and seamlessly woven into the workflow, it cannot be a secondary process slowing development.

           

          1. Compliance should be approached as an engineering problem. A significant challenge for financial services companies and fintech continues to be adhering to governance and compliance requirements. One of the reasons is a lack of automation and solutions that scale, which come at significant costs. In fact, one-third of global financial services companies spend more than 5% of their budget just on addressing compliance.Many financial services organizations rely on spreadsheets, PDFs, paper files and email chains to address and prove compliance. Fintech companies continue to address compliance questions using paper documentation and manual work. These methods are clearly not scalable and not sustainable for growing organizations to meet their expanding compliance demands.

            Fortunately, as the panelists uncovered, compliance and governance can be viewed through an engineering lens, as they have seen happen at some of the best fintech companies. One panelist illustrated that at his company he met with compliance experts to learn precisely about their problems, so his team could engineer solutions. After discovering the issues and metrics needed to prove compliance effectiveness, his team introduced automation and new tools to address the issues. His company knows the compliance methods are working if the metrics are being met, he said.

            Another panelist added that meeting regulatory compliance within a global organization like his introduces additional challenges of meeting compliance requirements in multiple jurisdictions. But the need to understand where data is and how it is being kept safe is common across the board. If you can address those questions, he said, then proving that the data is safe becomes the main task.

            For development and application security to remain sustainable, compliance cannot remain manual and human based. The panelists agreed that it’s unlikely to be able to fully automate all of the reporting and processes needed, but with a goal of 80% automation and 20% manual methods, organizations will be in a much better position.

          2. Security must be proactive. This is a common theme in our industry these days, and it certainly was popular thought the entire roundtable discussion. The panelists highlighted that fintech engineering teams are thinking about compliance and security in a variety of proactive ways. One panelist recalled that he asks his teams to “lean into security and do right by the customer before the company is asked to do so.”

      The areas addressed throughout the discussion ranged to a variety of topics, including how these days security is kept top of mind for engineering leaders during the hiring process. Participants agreed that hiring an AppSec developer is like finding a unicorn. The trick they said is to be more proactive and nurture your own unicorns internally. This can be accomplished by focusing on hiring top security developers and growing them into security roles. The result has significant benefits on all sides. The company will build its AppSec resources and expertise, and employees can value the opportunity to grow and expand their experiences into new areas they may not have known before.

      The panelists highlighted that exploring ways to ensure and accelerate approval for security features is a good way to ensure proactive security. One approach is to connect compliance issues that need addressing with security advancements. For example, if the goal to help prevent customer data loss is to add two-factor authentication, one should link a compliance issue that can also be solved by the requested security solution. Decision-makers may look to save budget and pass on simply adding security features, but it will be more difficult to say no to a compliance request. This kind of creative strategic thinking has a way of being a win-win for the company as well as its customers.

      The success of AppSec among financial services organizations depends on more than just effective security protocols that secure companies and protect customers. It needs creative, innovative and strategic ideas to enable organizations to have efficient, economical and scalable security. If that sounds like something your organization is seeking, then according to our roundtable panelists our industry has a very bright future.

  • How Service Mesh Enables a Zero-Trust Network

    How Service Mesh Enables a Zero-Trust Network

    How can we achieve high-grade security within a microservices ecosystem? Service mesh may be the answer

    Enterprise applications often assign an identity to humans to determine security clearances. Using standards such as OpenID Connect and SAML, we can delegate authorization scopes across a suite of applications to determine precisely what a user is permitted to do. But what about the applications themselves? Some believe that microservices should follow this identity-first approach, too.

    For large-scale application ecosystems, microservices is arguably more secure than a monolith. As Marco Palladino, CTO of Kong, described, “A monolithic application is a security incident waiting to happen.” Yet, microservices shouldn’t necessarily trust one another. So, how can we achieve high-grade security within a microservices ecosystem?

    The answer may lie in service mesh. I recently met with Palladino to discover how a service mesh can achieve bank-grade security for established and emerging microservices patterns. Similar to how enterprises assign an identity to end users, a zero-trust security network gives an identity to microservices themselves.

    A Zero Trust Network Trusts Nothing

    With more personal data used in cloud operations, more and more personally identifiable information (PII) is vulnerable to attack, and the costs are high. In Q1 2019, the cost of breaches in the financial sector was $6.2 billion. In 2018, 97% of breaches exposed PII, a top target for cybercriminals.

    Organizations are thus feeling pressure to secure their assets. The most precious data is held within financial services and health care, where GDPR and HIPPA enforce strict accordance with data privacy. This pressure is leading U.S. banks to clamp down third-party application access. Simultaneously, European banks face similar security dilemmas while appeasing PSD2 regulation for open banking.

    To safeguard user data, organizations are adopting a zero-trust security model. “Zero trust security means that we’re not trusting anybody,” said Palladino. “We don’t trust our own services. We don’t trust our own team members.”

    Placing too much trust in users, services and teams could cause a catastrophic failure. And, “there is no bigger risk than thinking you are secure, while in reality, you are not,” he said.

    Monolith ⮕ Microservices

    In practice, architecting a zero-trust application network runs parallel with the trend toward microservices designs. Though it may seem counterintuitive, a microservices system is arguably more secure than a monolithic architecture.

    In a monolithic application, every resource—whether invoices, billing orders or transaction history—is always just one line of code away. Since everything is connected, you could expose a resource with a single access.

    A microservices architecture decouples applications into separate services, each responsible for specific resources that make up the smaller applications, which can be secured and provisioned over a network.

    Segmenting the service landscape avoids one cascading defect affecting all applications. It also enables more control. “By decoupling from monolith to microservices, we can apply fine-grained security permissions and rules to determine what’s possible in the context of the application,” Palladino said.

    Microservices ⮕ Service Mesh

    Implementing these permissions is where a service mesh comes in. The application teams often build security, yet it’s generally bad practice to build your own cybersecurity. Security for microservices requires high expertise, and standardizing connectivity between various microservices can easily result in fragmented security implementations.

    Instead of building your own security infrastructure, Palladino recommended utilizing service mesh. By using service mesh as a control plane for microservices, platform architects can specify specific rules and attributes to generate an identity on a per-service basis.

    Service mesh also removes the burden of networking from developers, enabling them to focus more on their core logic. “Application teams become consumers of connectivity, as opposed to the makers to this connectivity,” Palladino noted.

    Identity for Services

    In the same way enterprises create identity profiles for humans, Palladino said we must extend the same model to services, pairing each service with authorization scopes. “Services must provide their own identity,” he noted. “Based on that, they can do certain operations in their infrastructure.”

    When we think of identity for services, attributes such as geographic location and certificates come to mind. These and other traits could make up a microservice’s authorization scopes. Utilizing a service mesh, architects could assign such attributes to each workload and service to determine what operations are allowed or what requests can be made to what other services.

    For example, services from one region could be designed not to consume services from another region. Such attribute-based control for microservices is a novel, well-needed strategy, Palladino said. “It was crazy this was not in place before; not having zero trust is like having all your money in an open vault.”

    Best Practices for Service Identity

    Knowing that we want to implement identity-based security for microservices, where are some best practices? Palladino recommended:

    • Automate some attributes: A service mesh could automatically assign identity attributes upon creation, such as cloud zone or geographic boundaries.
    • Provide a way to manage attributes: A dashboard would be necessary for DevOps engineers to create, edit or delete service-level attributes.
    • Governance: Architects must manage the control plane and create identities for the right parties to access this capability.
    • Secure encryption and Mutual TLS: Teams will require a system for rotating and expiring certificates for hundreds of thousands of workloads running across an organization, noted Palladino.
    • Standardize: Secure Production Identity Framework For Everyone (SPIFFE), a CNCF incubating project, is a good framework for service identity, making it operable with other cloud-native projects.
    • Play nice with CI/CD: Attribute creation could be hooked into an underlying CI/CD process to occur when deploying products automatically.

    Once microservices have identities, the services they interact with can determine what actions they are authorized to perform. This limits machine-to-machine communication to allowed operations.

    Zero-Trust Security With One Click

    Many teams have transitioned to a microservices architecture to deploy more often, be more distributed, decoupled or improve overall reliability. While these innovations are largely positive, Palladino cautioned against innovation without the proper security forethought: “It’s silly to transition to a microservices strategy without thinking about how these services are secured,” he said.

    Teams will also be running microservices on various environments—VMs, cloud or physical data centers. Thus, considering microservice-to-microservice communication, how do we route traffic between such environments? How do we observe metrics and logs? Palladino believes an agnostic service mesh that supports multi-region, multi-zone, multi-cloud and hybrid modes is the answer to these dilemmas.

    If used correctly, service mesh can plug security gaps for internal service-to-service communication, thus obfuscating high-value resources, such as financial services data, from nefarious players. The key to solving the service identity challenge is a usable dashboard. As Palladino described, “Zero trust security with one click.”

  • DevOps’ Role in Fixing Software Vulnerabilities

    DevOps’ Role in Fixing Software Vulnerabilities

    From the beginning, application development has required that software developers deal with bugs, vulnerabilities and other issues. But problems encountered under the DevOps model tend to be more manageable since the updates and fixes required are usually smaller. The reason for this is that the process of maintaining and improving DevOps-related software never stops. In other words, problems that do need to be corrected are typically tackled faster under the DevOps model.

    In looking at the DevOps cultural shift that has fast-tracked the software development process while making security part of that process, it’s critical to consider how the DevOps process impacts software development, the issues around hackers taking advantage of vulnerabilities in code and why companies need to protect their infrastructure that incorporates speed and security.

    How DevOps Practices Impact Software Development

    DevOps practices impact every level of the software development process. In the past, software developers would churn out new app versions, sometimes every few years and sometimes every couple of months.

    This afforded developers sufficient time to go over their code with a proverbial fine-tooth comb. It also allowed them to devote more time to quality assurance efforts, which helped to minimize vulnerabilities that hackers could use to their own advantage.

    But the rise of DevOps has drastically revolutionized the way software is developed and delivered to customers. Instead of releasing new versions of apps perhaps yearly, software developers operating under the DevOps model can release updates and fixes quickly and on an ongoing basis.

    Facilitating the software development process over the course of the DevOps life cycle are tools such as Jenkins or Docker that allow the automation of many procedures and applicable processes.

    Quite simply, DevOps practices positively impact software development. The benefits can be broken down into three categories, namely technical, cultural and business, and as can be seen below:

    1. Technical Benefits: Ongoing software development, less complexity to take on and faster resolution of problems or issues.
    2. Cultural Benefits: Teams more fulfilled and productive, greater worker engagement and more professional development options.
    3. Business Benefits: Speedier delivery of features, more durable operating environments and better collaboration.

    It goes without saying that DevOps has a major and even revolutionary impact on the process that software development teams use to create applications as well as to fix vulnerabilities. It proves that doing things faster doesn’t have to mean proceeding in a haphazard manner.

    Issues Around Hackers Exploiting Code Loopholes

    Implementing the right processes and procedures can cut down on exploitable vulnerabilities. But software developers understand that hackers wake up each morning scheming up new ways to exploit code and infrastructure, which is why the struggle never stops. One of the issues customers are justifiably concerned about is privacy.

    The answer is to take DevOps to the next level. In other words, software developers need to adopt the DevSecOps model, which refers to implementing open source security procedures in the beginning stages of the software development life cycle. Open source security measures are essential for DevOps security teams because of the fact that they are lower cost, more innovative and allow teams to make the most of their continuous delivery processes. This includes, but is not limited to, code analysis, vulnerabilities assessments and compliance monitoring.

    When software teams purposefully and intentionally implement security practices within an Agile framework, they will be able to safeguard the integrity of their codebase. This can be accomplished with continuous evaluation, testing and updating.

    Why Businesses Need to Maintain Fast and Secure Infrastructures

    More companies are investing in protecting their infrastructure than they ever have before, as infrastructure protection spending this year could reach $17.5 billion worldwide, up from $12.6 billion in 2017. So while there is crystal clear evidence that more companies recognize the need to protect their infrastructure from nefarious actors, they are also, in fact, doing something about it.

    The consequences of failing to maintain a fast and secure infrastructure can be disastrous. Consider the following statistics that show some of the problems that can materialize: On average, it takes 206 days just to identify a data breach, and over 30% of companies encountered cyberattacks on operational technology infrastructure last year alone.

    So what can software development teams do to help organizations maintain secure infrastructures at a time where hackers are tirelessly persistent? While customers expect software to be delivered post-haste, they also expect it to be secure.

    Software developers need to commit to DevOps and DevSecOps to ensure that the software they develop and deliver to customers is free of exploitable vulnerabilities that could jeopardize their infrastructure, scare off their clients and even potentially wreck their operations altogether.

    Customers also have a role to play to keep their infrastructure safe. They should, for instance, have policies in place to govern how their workers use the software, roll out updates and fixes as soon as they are available, and use the right tools to protect their infrastructures.

    Conclusion

    By leveraging the DevOps model to make security part of the corporate culture and by training team members so that everyone adopts coding habits that are rooted in security, and by automating security in the development process, software development teams can deliver safe products quickly.

    At a time when customers expect deliverables fast, software development teams need DevOps so they can go from the development stage to the delivery stage without needless delay. The DevSecOps model is one in which security is purposefully implemented at each stage of the software development process, not simply a value-added component.

  • GrammaTech Discovers Vulnerabilities in Third-Party Code

    GrammaTech Discovers Vulnerabilities in Third-Party Code

    GrammaTech today launched a CodeSentry software composition analysis (SCA) for binaries that inventories third-party code used in custom applications and identifies known vulnerabilities.

    Vince Arneja, chief product officer for GrammaTech, said the bulk of custom applications today are made up of binaries based on components developed by a third-party that comes in the form of open source, commercial-off-the-shelf (COTS) or existing custom software.

    CodeSentry detects these components and vulnerabilities associated with third-party code, including network components, graphical user interface (GUI) components or authentication layers. It uses deep binary analysis to create a detailed software bill of materials (SBOM) and a comprehensive list of known vulnerabilities.

    Arneja said that as responsibility for security continues to shift left toward developers, there is a need for tools such as CodeSentry that make it easier to identify vulnerability issues in binaries because many developers may not have access to the underlying source code used to construct the binary. CodeSentry identifies components present in native binaries using a range of matching algorithms to gather version number ranges, create an SBOM and provide links to CVE and CVSS scores, said Arneja.

    CodeSentry extends algorithms that GrammaTech developed to detect components in applications, including strings used in natural language processing. It maps components to multi-dimensional vectors and compares them to vectors derived from the components. The upload interface for the tool accepts native binaries, zip files and other archives. Once those files are loaded, CodeSentry analyzes the code that will run rather than the build environment to reduce the number of false positives that would be generated in build environments or components that are not actually being employed.

    GrammaTech next year intends to make CodeSentry available via a software-as-a-service (SaaS) platform, noted Arneja. GrammaTech ultimately envisions CodeSentry being employed as part of DevSecOps workflows driven by a continuous integration/continuous delivery (CI/CD) platform using a set of open application programming interfaces provided by the company, said Arneja.

    While there’s a lot of focus these days on melding DevOps and cybersecurity workflows as part of an effort to embrace best DevSecOps practices, the easiest vulnerability issue to resolve is the one that never existed in the first place. As developers gain access to cybersecurity tools, the number of vulnerabilities making it into applications should significantly be reduced in the months ahead. The challenge IT leaders face is making sure developers have access to those tools, which in turn will ultimately boost the confidence level cybersecurity teams have in application developers, who are often viewed as the primary cause of the problems cybersecurity teams are trying to resolve.

    Regardless of how IT organizations achieve that goal, the return on that investment is likely to be substantial. The amount of time and effort IT teams spend tracking down vulnerabilities that are much more expensive to fix after an application is deployed in a production environment is incalculable.

  • How to Successfully Integrate Security and DevOps

    How to Successfully Integrate Security and DevOps

    As digitalization transforms industries and business models, organizations increasingly are adopting modern software engineering practices such as DevOps and agile to become competitive in the modern marketplace. DevOps enables organizations to release new products and features faster, but this pace and frequency of application releases can conflict with established practices of handling security and compliance. This leads to the enterprise paradox to go faster and innovate but stay secure by avoiding compromises on controls.

    However, integrating security into DevOps efforts (DevSecOps) across the whole product life cycle rather than being handled independently or left until the end of the development process after a product is released can help organizations significantly reduce their risk posture, making them more agile and their products more secure and reliable. When properly implemented, DevSecOps offers immense benefits such as easy remediation of vulnerabilities and a tool to mitigate against cost overruns due to delays. It also enables developers to tackle security issues more quickly and effectively. Getting security right from the start is important due to the growing dependence of companies on digital technologies that can make them more susceptible to cyberattacks, in which an attacker can utilize a system flaw possibly created due to unfamiliarity toward security as a business priority.

    DevSecOps integrates various security challenges into the coherent approach of software delivery. Some best practices followed in DevSecOps throughout the software development life cycle are:

    • Planning and Designing: From the inception, teams are aware of their security responsibilities and trained to handle them. Since the start teams quickly model threats and risks. Product backlog items (PBI) are prioritized in a way to make the product secure and compliant. Architectural design is developed in collaboration with security experts.
    • Coding: Developers practice secure and resilient coding practices. Full advantage is taken of reusable coding patterns and microservices to meet common security requirements for encryption and authentication.
    • Reviewing: Both automated and manual checks are used to review codes as part of regular agile sprints. After that, peer reviews are conducted by senior developers to make sure that software meets appropriate standards.
    • Testing: Automated security tests are run alongside automated functional and performance tests to confirm that testing is consistent. Automated penetration tests look for security cracks in systems as part of every sprint and release cycle.
    • Deployment: Automated processes are used to deploy code securely and reliably into production-hosting environments that can be rapidly invoked through APIs.
    • Operations: In production, automated processes such as real-time monitoring, intrusion detection and compliance validation are used to detect vulnerabilities. Product reliability and security are constantly checked to detect vulnerabilities and prioritize resolutions.

    The success of adopting DevSecOps principles relies on avoiding common pitfalls. The mere implementation of DevOps tools across the organization cannot support the effectiveness of DevOps. To get it right, companies need to:

    • Create a more integrated operating model making privacy and security principles as integral parts of the company culture.
    • Build secure and reliable services.
    • Wherever possible, automate development and release processes.
    • Continually evolve product architectures.

    Leaders play an active part in steering the transformation by endorsing security and privacy at the board level. At the same time, CISO and compliance leaders need to make certain that greater agility does not come at the cost of higher risk.

    Often organizations focus on software security as a business priority only after they are affected by a data breach. But when an organization is impacted by cybercrime, along with the costs of data damage, IP theft and business disruptions, it incurs legal and PR fees, drops in share price and the potential loss of customers and competitive advantage.

    Companies that implement DevSecOps best practices benefit from numerous advantages. Substantial costs can be curtailed by detecting and fixing security issues in the early phases of development, which indirectly leads to an increased speed of delivery and recovery.

    A secure and reliable product has the potential to increase sales. Following best practices leads to the creation of immutable infrastructure and utilization of cloud-based infrastructure that helps improve overall security by reducing insecure defaults, increasing code coverage and automation.

    Automated application testing, automated security review of code and empowering developers to use secure design patterns ensure the “secure by design” principle. In DevSecOps the responsibility for security is shared and encourages a culture of openness and transparency from earlier stages of development and enables constant iterative improvements.

    A central belief of DevSecOps is that security is an integral and essential aspect of DevOps. By adopting DevSecOps best practices in their product development cycles and avoiding common pitfalls, companies can stay current, acquire agility and strengthen their security to withstand exposure to cyberattacks.

  • DevSecOps: Changing AppSec for the Midmarket

    DevSecOps: Changing AppSec for the Midmarket

    The midmarket space has always been prime for innovation and opportunity. In the DevSecOps space, that is no different.

    If you look at this report or others about DevSecOps markets, two things stand out:

    1. The market is expected to explode to $14 billion by 2026 from today’s nominal $2 billion.
    2. The biggest driver of the increase is the rise of security adoption by midmarket enterprises.

    Software is eating the world, as everything is becoming digitized. In response, midmarket companies are rapidly cranking up web and mobile apps to better compete and serve their customers. Along with the increase comes a dependency on apps for critical business functions and a need to secure them from attacks, which explains the surge in security demand.

    Current AppSec Offerings Are Not Geared for the Midmarket  

    AppSec Expertise Required

    Most incumbent AppSec products were built at least a decade ago when only large enterprises cared about AppSec. Naturally, they were molded for the characteristics of those enterprises. They are unnecessarily deep and monstrously complex and require a team of AppSec experts to begin operations. Midmarket companies don’t have the skills, resources or willingness to hire a team of AppSec experts, especially given their short supply.

    Extraordinarily Expensive

    Incumbent AppSec products are dreadfully expensive for midmarket companies. Annual prices reach millions of dollars and it’s difficult to determine ROI, making decisions murky for budget-conscious midmarket companies. They want to produce and deliver secure apps and certainly want to mitigate risk, but they also have a lower ceiling they can afford to pay.

    A New AppSec Approach for the Midmarket

    Being Cloud-native Requires SaaS AppSec

    Midmarket companies are quicker to adopt a cloud-native approach. Unlike large enterprises, they don’t have the baggage of legacy tech and can move to the cloud more easily. Being cloud-native saves a lot of money and comes naturally to the midmarket—when it comes to AppSec, they are likely to require that products be cloud-native and SaaS. Most security incumbents started on-premises, and although some now have a parallel SaaS offering, they are clunky and not designed inherently for cloud-native architectures.

    Rise of DevOps and CI/CD Automation

    As cloud adoption increases, automation of deployment to the cloud becomes a key factor, resulting in the meteoric rise of DevOps. DevOps uses many tools to automate cloud integration and cloud deployment, with CI/CD tools consistently at the center. AppSec must be part of this automation process, preferably in the CI/CD. The manual waterfall approach cannot work with the new speed and volume of application development. If scanning is not automated in the CI/CD, scans simply don’t get run. Therefore, because the automation workflow starts with DevOps, AppSec needs to be DevOps-first.

    Traditional AppSec scanners were not built for DevOps. Sure, some have caught up and added DevOps to their marketing material. Several have even added some integrations, but their core product remains much the same and it’s not DevOps-friendly.

    One significant offshoot of DevOps-first AppSec for the midmarket is that the tool cannot require AppSec expertise, simply because most DevOps don’t have significant AppSec expertise. Requiring that knowledge to get the security automation workflow started is a non-starter.

    Open to Open Source Scanners … With Management

    Midmarket companies are typically willing to use open source primarily because it is free. Unlike large enterprises with their tendency to complicate anything, midmarket companies have fairly standard requirements that can usually be met with open source. It is no different when it comes to application security scanners, and midmarket enterprises are fans of these tools. Often the scanning prowess of these open source scanners is better than their commercial counterparts, as they are tailored and specialized to specific languages and architectures. They also cover all scan types (SAST, DAST, SCA, etc.) and a combination of them can provide an efficient and affordable level of security.

    This midmarket love affair with open source scanners comes to a screeching halt when it becomes apparent that it is grossly unmanageable. There are so many available open source scanners that it takes time to decide which are relevant for your organization, application and development status. They are also notoriously difficult to set up, upgrade and maintain. Each of them does things differently. The output or reporting formats are not normalized across scanners. Without an aggregation layer to consistently cross-reference, normalize and present a consistent view of the security risk, consuming the output is nearly impossible. This often results in midmarket companies choosing to select only one type of scan.

    Imagine a tool that adds a common SaaS orchestration layer that crosses all these scanners and scan types, using their superior scanning prowess, but removing the management headache. Midmarket companies would improve their security posture with an investment they can afford. This sort of “Open Source + SaaS” model is not new. Applying the model to application security changes the game for midmarket companies.

    One Tool for all Scanning

    The multiple types of application security scans make application security complex. SAST scanners scan the source code for vulnerabilities, DAST scanners scan running applications from the outside in, SCA/OSS scanners scan third-party libraries included in your application, container scanners scan containers, API scanners scan exposed APIs, Secrets scanners scan for open passwords in the source code, and so on. Mentioning all these distinct scanners can make heads spin for those inexperienced with AppSec. This complexity is worsened for midmarket companies. For most, it is nearly impossible to keep up with the new pace of application development with unaffordable, piecemeal scanners from multiple vendors or the multiple open-source scanners needed to address each area of vulnerability.

    Security is only as good as the weakest link. Even if you do an exemplary job with one type of scanning but leave out other types you leave gaping holes in your security and risk. What midmarket companies need is one tool that tackles application security comprehensively by automating and orchestrating the use of all types of scans while abstracting the user from the underlying complexities.

  • Using PAM to Support the ‘Sec’ in DevSecOps

    Using PAM to Support the ‘Sec’ in DevSecOps

    Despite its reputation as slow and complex, PAM can be included in the DevOps pipeline effectively

    The introduction of DevOps practices has led to a revolution in software development. However, as companies adopt these new technologies, tools and methodologies, incorporating privileged access management (PAM) becomes increasingly complex. Nonetheless, corporate policies, industry standards and government regulations mandate that security and operations teams must manage and audit permissions and credentials for a growing number of user and service accounts. As a best practice, a least privilege access control model is a must.

    Compounding the issue is that traditional methods of securing developer environments involve manual interventions and restrictive controls that significantly hamper the agility of development and operations teams. Because of that, DevOps has eschewed PAM as too slow and complex to deploy and manage.

    Adding to the complexity, applications, virtual machines, services and workloads running in the cloud all have identities. In fact, non-human identities nowadays represent most “users” in many organizations. This proliferation of non-human identities exacerbates the difficulty of achieving least privilege.

    Like human identities, access for these identities must be strictly monitored and controlled so that unauthorized, unverified access is automatically denied. PAM solutions that support modern application-to-application password management (AAPM) approaches can achieve this. DevOps owners can take control of privileged access without impacting agility, leaving them to focus on what they do best while finally putting the “Sec” into DevSecOps.

    AAPM eliminates the need to store credentials in clear text in the application. Instead, developers introduce API calls in their code to access a vault programmatically and to check out the password. The password is stored in application memory and not written to disk. Once the application terminates, the memory is deallocated and the password is gone, leaving nothing for a threat actor to find. Using this approach, the vault secures the credentials and controls access to them. The vault can also automatically rotate passwords, making them more challenging to crack. Since dependent applications now make API calls to fetch them, DevOps teams are no longer concerned with updating their code whenever the passwords change.

    PAM and DevOps: AAPM in Action

    This is a fundamental approach to AAPM. Other options exist, however, distinguished by increasing levels of cyber-risk mitigation and operational efficiencies:

    Level 1: AAPM to Retrieve a Vaulted ID and Password

    As described, this is the traditional approach to PAM. While vaulting the passwords provides an extra layer of security by removing them from code, passwords remain the weakest form of authentication. Even with automatic password rotation, they persist until the next scheduled rotation (often days or weeks), giving an attacker ample time to attempt to crack. To check them out of the vault, each workload needs a service account. This can quickly amount to hundreds, if not thousands, of additional accounts, increasing administrative overhead and increasing the attack surface.

    Level 2: AAPM to Retrieve a Vaulted ID and SSH Key

    Human administrators and workloads present an added risk to organizations through the widespread use of shared privileged accounts for authentication. Secure Shell (SSH) keys are frequently implemented as a safer alternative, allowing the workload to check out a vaulted SSH key instead of checking out a vaulted password.

    The use of SSH keys includes similar risks and benefits to vaulted passwords. They’re also static, relying on a scheduled rotation. They, too, can be shared among developers and between workloads. Developers and IT admins are often given enough rights to create SSH keys at will without any oversight or central management. This makes them difficult to track and know how they’re being used, by whom and for what. If they’re lost or if a developer leaves, system and service availability can be impacted.

    On the positive side, however, the SSH protocol employs public-key cryptography. The SSH keys (public and private) are longer and more complex than any password. Unlike passwords, they’re not sent over the wire. All this makes them more difficult to compromise and, thus, more secure.

    That said, each workload still needs a service account to authenticate to the vault and check out an SSH key, each of which is a potential vector of attack.

    Level 3: AAPM to Retrieve Ephemeral Tokens

    Ephemeral tokens (e.g., OAuth2) can be created automatically by the vault on-demand and offer a modern form of secure access that is temporary, time-based and expires automatically. This releases DevOps from dealing with installation, configuration and rotation issues while contributing to a best-practice “just-in-time” access control approach. As with the earlier methods, however, each workload still needs a service account to authenticate to the vault to obtain a token.

    Although such tokens can persist, they’re generally short-lived for the duration of a session or transaction, greatly reducing the window of opportunity for a threat actor. 

    Level 4: AAPM Using Delegated Machine Credentials and an Ephemeral Token

    The prior methods are all characterized by a per-workload service account requirement. With a Delegated Machine Credential approach, a service account is only required per-machine.

    When the machine is enrolled in the PAM service, it establishes a mutual trust relationship. The PAM service creates a unique Delegated Machine Credential, machine identity and service account for that machine. Local workloads can then piggy-back off that machine identity, leveraging the delegated machine credential to authenticate to the vault, exchanging it for an OAUth2 bearer token it can use for subsequent API calls (e.g., to check out a password or obtain a token.) Since not all workloads are equal, OAuth scoping can limit which APIs each workload is allowed to access. Thus, by using a Delegated Machine Credential, the number of service accounts is reduced to practically zero, closing thousands of potential vulnerabilities.

    This approach also addresses the lack of desire to introduce PAM into DevOps, as I highlighted right at the start. This method can be fully automated and inserted naturally into the CI/CD pipeline.

    All these approaches give organizations more choice, based on their existing PAM maturity, risk tolerance, and compliance pressures. They ultimately allow DevOps teams to automate, simplify and centralize PAM security management while improving the organization’s security posture, without sacrificing agility.

  • Snyk Brings AI to DevSecOps

    Snyk Brings AI to DevSecOps

    Snyk today at its SnykCon 2020 conference announced a static application security testing (SAST) dubbed Snyk Code that incorporates an interpretable machine learning semantic code analysis engine the company gained through its acquisition of DeepCode earlier this year.

    The company also announced it has extended its alliance with Docker Inc. to become the exclusive provider of security insights for both Docker Official Images and future content certification programs from Docker. Available via Docker Hub, Docker Official Images are a collection of 166 curated container images that developers frequently reuse.

    At the same time, Snyk today announced it has integrated its vulnerability database with the IT monitoring service provided by Datadog as well as the IBM Cloud service.

    Snyk President Guy Podjardny said Snyk Code is aimed specifically at developers as part of an effort to advance the adoption of best DevSecOps practices. It provides visibility into application source code, open source libraries, container infrastructure and infrastructure as code to enable developers to better secure applications as they are being built.

    The company claims Snyk Code is up to 50 times faster than traditional SAST solutions, which would represent a major boost in productivity for developers who often don’t have the patience required to scan code as much as IT security teams would prefer.

    Snyk Code also curates machine learning models using the company’s curated vulnerability database to significantly reduce false positives. It also automatically models application programming interfaces (APIs) based on the best practices observed by the platform.

    Snyk Code is also designed to be integrated with CI/CD platforms to streamline DevSecOps workflows.

    Podjardny said Snyk went beyond simply productizing the Deep Code tool to incorporate capabilities that would specifically appeal to developers rather than cybersecurity teams. Given the volume of code that needs to be scanned before and after code is deployed in a production environment, Podjardny said it’s apparent that DevSecOps isn’t going to be achieved without augmenting developers with artificial intelligence (AI) tools.

    It’s not clear at what rate responsibility for IT security is shifting left toward developers. Beyond simply providing developers with the tools required to analyze code, workflows that DevOps and cybersecurity teams currently rely on must be better integrated. That’s a challenge, because the current rate at which DevOps teams are updating applications typically exceeds the ability of a limited team of cybersecurity professionals to keep pace. The days when cybersecurity teams could have weeks to review an application before being deployed are all but over.

    It may take a while for DevOps teams to gain confidence in AI tools. However, it’s clearly not feasible for human developers to identify every potential vulnerability within thousands of lines of code running on multiple platforms that can have any number of vulnerabilities which developers are not likely to know much about. As such, it’s not so much a question of if AI will play a major role in enabling DevSecOps as much as when.

  • Code Security: SAST, Shift-Left, DevSecOps and Beyond

    Code Security: SAST, Shift-Left, DevSecOps and Beyond

    Automation is the key to pushing code security beyond DevSecOps

    In virtually every industry, developers are dealing with ensuring the safety of their code. Regardless of whether it’s enterprise or applications for automotive, aviation or industrial controls, small systems or large systems, every organization struggles with security. In response, the industry continues to evolve to improve automation, speed of delivery and code reliability. Let’s consider the key building blocks of today’s application development ecosystem.

    Static analysis or static application security testing (SAST) helps enforce coding guidelines and detect undefined behavior, and is commonly used across the development ecosystem. One advantage of SAST is automation. Since it doesn’t require input, SAST is easy to introduce into an existing software development process where it will inspect source code builds and generate warnings. Coding guidelines such as MISRA, CERT C and others help avoid common programming mistakes. However, a second category, undefined behavior, is a bigger issue. That’s because undefined behavior introduces risk. For example, a null pointer dereference, buffer overrun or uninitialized variable are exploitable vulnerabilities. Depending on their severity, they typically will require issuing a patch for customers.

    Next, let’s consider DevSecOps, which spans development, security and operations. Although it is becoming widely adopted in enterprise markets such as financial services, markets such as automotive and industrial are lagging. Nevertheless, the emphasis on security is driving the DevSecOps push to make life easier for software developers and to bring them more in line with security and operations functions.

    For example, quick feedback cycles are extremely important in every industry. Consider a use case in which it can take up to an hour to deploy a newly developed feature or a fix once it is written. That’s unthinkable in today’s day and age when new source code must run almost instantaneously.

    One of the most important elements in DevSecOps revolves around a project’s branching strategy. In addition to the main branch, every developer uses their own separate branch. They develop their code and then merge it back into that main branch. A key requirement for the main branch is to maintain zero unresolved warnings so that it passes all functional testing.

    Therefore, before a developer on an individual branch can submit their work, it also needs to pass all functional tests. And all static analysis tests need to pass. When a pull request or merge request has unresolved warnings, it is rejected, must be fixed and resubmitted. These include functional test case failures and static analysis warnings.

    Functional test failures must be fixed. However, the root cause of the failure may be hard to find. A functional test error might say, “Input A should generate output B,” but C comes out instead, but there is no indication as to which piece of code to change. Static analysis, on the other hand, will reveal exactly where there is a memory leak and will provide detailed explanations for each warning. This is one way in which static analysis can help DevSecOps deliver the best and most secure code.

    Finally, let’s review Lean and shift-left, and see how they are connected.

    Lean development is focused on delivering value to the business. If we fix this defect, is the business going to get value? If we fix this warning, is the business going to get value? In other words, eliminate waste, make the right decisions, at the right point in time.

    Zero defects is actually one of the big underlying philosophies behind Lean. And of course, zero defects never means zero defects. It really means near-zero defects. For example, when there’s no value in fixing a particular defect, it can be classified as don’t fix. Meanwhile, if a defect exists such that an application will behave badly when a user inputs a negative value in the add function, there are two options: Fix it or don’t fix it, if the expectation is users will never input negative values.

    The objective is to achieve a zero-defect baseline and continuously improve. In this scenario, zero defects refers to source code problems as well as warnings from static analysis.

    Last is the concept of shift-left, which is a movement to bring certain processes closer to the developer—testing, in this case. By providing faster feedback cycles on new code, developers can avoid slowdowns. When working on source code projects, if regression tests run several days after a block is submitted and reveal defects, it can be difficult for developers to recall what they worked on at the time. Faster feedback that occurs in minutes, not days, improves quality and security. In this way, shift-left is a central component of DevSecOps and Lean. And static analysis is part of that shift-left.

    So what’s next? In a word, more automation. Making sure developers have as little cognitive overhead as possible will allow them to build code faster and more securely. This can be achieved by combining the concepts described above as well as analyzing code as soon as new functionality is developed using behavior-based testing or test-driven development. The ultimate goal is faster feedback cycles that accelerate development cycles.

  • Runtime Security and Incident Response with Loris Degioanni

    Runtime Security and Incident Response with Loris Degioanni

    By adopting DevOps, Kubernetes and containers you can accelerate innovation and deliver a better experience for customers and employees. While Kubernetes adoption simplifies application deployment, security needs to adapt and be cloud-first, open and frictionless as a new set of complexities may surface.

    Check out this interview with Sysdig Founder and CTO Loris Degioanni to find out how you can manage the health of your applications and learn more about runtime security and incident response.

    Loris is a security expert and an open source veteran, and he’s also one of the keynote speakers presenting at this year’s DevOps Experience Virtual Summit. During his presentation, Loris will share his perspective on where security is going and practical advice for managing security risk in a Kubernetes and DevOps world.

    For more insights and tips on Kubernetes security, attend Loris’s keynote session at DevOps Experience 2020 on Oct. 22. To check out the full agenda or to register for free, visit the DevOps Experience website.