devopsy.kinsta.cloud

Category: DevSecOps

  • Raytheon Leans on Red Hat to Advance DevSecOps

    Raytheon Leans on Red Hat to Advance DevSecOps

    Raytheon Company is partnering with Red Hat to drive the adoption of DevSecOps workflows and processes it developed around the OpenShift application development and deployment platform.

    Jon Check, senior director for cyber protection solutions for Raytheon Intelligence, Information and Services, said Raytheon has developed a set of DevSecOps practices for organizations building applications deployed in highly secure environments, involving government contracts.

    Raytheon and these customers have been challenged by a chronic shortage of IT professionals with the appropriate level of clearance to work on these classified projects. To overcome that issue, Check said Raytheon developed what it describes as a “code low, deploy high” approach to DevSecOps. Developers who lack security clearances can still build applications; however, those applications can only be deployed by IT professionals having the appropriate security clearance.

    In addition, Check said Raytheon has developed integrations between its DevSecOps framework and various IT tools based on the ITIL framework, which so many IT operations teams depend on to foster collaboration across the application development and deployment process. For example, he said, whenever code gets checked into a repository, an alert can be sent to an IT service management application from ServiceNow.

    That approach enables organizations to build applications quickly without compromising the integrity of the deployment platform, Check noted. Now Raytheon is working with Red Hat to drive adoption of its approach to DevOps to organizations beyond the core vertical industry and government sectors it serves.

    Check said Raytheon chose to work with Red Hat because organizations are now building applications employing microservices based on containers that they want to be able to deploy on any cloud computing environment. Those environments include edge computing platforms to process data in near real-time closer to the point where data is collected.

    In addition, Check noted Red Hat OpenShift is built on Red Hat Enterprise Linux (RHEL), the first operating system to achieve Common Criteria certification with Linux Container Framework Support. Red Hat also assumes responsibility for curating the underlying open source operating system and application deployment platform.

    In general, Check noted that while there’s a lot of interest in deploying code faster these days, the deployment of insecure applications is counterproductive. Organizations too often find themselves rolling back application deployments to deal with one cybersecurity issue or another. By separating application development and deployment, Raytheon is making the case for a DevSecOps approach that enables more secure application code to be deployed faster, he said.

    Each organization will have to determine what rate of application deployment is fast enough for them. The more sensitive the application is, the more an organization is likely to want to be more deliberate when it comes time to deploy and update an application. However, the need to be deliberate doesn’t necessarily mean organizations should continue to rely on legacy approaches to application development and deployment based on waterfall methodologies.

    — Mike Vizard

  • DevSecOps Adoption and the Web Security Myth

    DevSecOps Adoption and the Web Security Myth

    As DevOps practices have become widespread in the tech community, many people have begun proclaiming the virtues of DevSecOps. As the name implies, DevSecOps is the addition of security into DevOps. Just as DevOps promises better-quality production in less time, DevSecOps promises better security with less time required to achieve and maintain it.

    DevSecOps has many benefits. However, many executives are under the impression they can’t embrace DevSecOps across their entire organization.

    This idea is false. Most organizations that have already adopted DevOps can, and should, take the next logical step and adopt DevSecOps as well.

    ‘It Sounds Great, But We Can’t Use It Here’

    Adopting DevOps requires far-reaching changes throughout an organization. Going to DevSecOps can be similarly disruptive. However, internal disruption is not usually the (perceived) problem with DevSecOps.

    Instead, the problem is usually the network border. Many executives believe that their current web security solutions are incompatible with DevSecOps.

    In many cases, this is actually true. Older approaches to web security are indeed hindrances to DevSecOps practices.

    Therefore, the problem isn’t actually with DevSecOps. The problem comes from the security solutions currently in use.

    Legacy Security Solutions and DevSecOps

    Many organizations are still using appliances (whether physical or virtual) as their primary protection against external threats. A decade ago, appliances were good enough. Today, they’re a competitive disadvantage.

    There are several ways in which appliances are incompatible with DevSecOps:

    • Programmatic control of an appliance is often difficult if it’s even supported at all.
    • Configuring an appliance can be challenging. It often requires a high level of security expertise.
    • Rolling out settings and configuration changes across a bank of appliances can be time-consuming and potentially error-prone.
    • The cost and specialized nature of most appliances make them inconsistent with the DevOps mantra of “cattle, not pets.”
    • Physical appliances do not scale.
    • External-facing applications will be limited in their scaling as well.
    • Appliances are not designed for ephemeral workflows.
    • Appliances are not designed to support infrastructure as code (IaC).

    Security appliances represent a decades-old approach to security, so it’s not surprising they don’t support modern practices. What is surprising is that even many allegedly “cloud-native” solutions aren’t built for DevSecOps, either.

    For example, some require multiple instances to be launched into your environments. Some require additional layers of management just to maintain consistent configuration among them. Many do not provide good support for evolving architectures and expanding deployments. In general, these security products tend to require significant intervention and management, while lacking automated control capability. This all severely limits the use of DevSecOps.

    These appliances and incorrectly labeled “cloud-native” solutions are why many executives believe DevSecOps isn’t an option for their organizations. To be clear, these executives are correct—for as long as they continue to use previous-generation approaches to web security.

    Not Just a DevSecOps Issue

    Older approaches to web security have other problems that go beyond a hindrance to DevSecOps usage.

    For example, appliances are marketed as complete web security solutions, but they cannot actually fulfill this role. Among other things, an appliance cannot defend against a volumetric DDoS. The attack can overwhelm the upstream ISP before the appliance even has a chance to scrub the traffic. This can result in the ISP blackholing all incoming traffic, which makes the targeted site and web applications unavailable to users and customers—which is the exact situation the appliance was supposed to prevent.

    Solving the Problem

    Organizations which are still using older security technologies should re-evaluate this decision. Modern solutions such as cloud web security platforms can provide better protection, along with numerous other benefits. These include full management by the provider, real-time reporting and traffic control, adaptive threat identification based on machine learning and much more.

    When organizations continue to use legacy security solutions, they not only prevent themselves from enjoying the benefits of DevSecOps, they are also missing out on many other benefits as well.

    — Maksim Blishchik

  • NetFoundry Network Overlay Advances DevSecOps

    NetFoundry Network Overlay Advances DevSecOps

    NetFoundry, at the recent KubeCon + CloudNativeCon 2019 conference, announced the general availability of a developer platform designed to make it easier for organizations to bake a zero trust networking framework within their applications.

    Company CEO Galeal Zino said NetFoundry has created a network fabric overlay to manage and secure communications between endpoints and applications. Developers now can embed a programmable zero trust networking framework within their applications using a NetFoundry Developer Platform, which consists of software development kits, application programming interfaces (APIs) and connectors, said Zino. DevOps teams can either consume the entire NetFoundry Developer Platform or only the open source components that have been included.

    At the same time, NetFoundry announced it has joined the Cloud Native Computing Foundation (CNCF) to advance the adoption of open source networking services for containerized applications.

    NetFoundry

    Rather than having to become intimately familiar with networking protocols, Zino says NetFoundry provides a layer of abstraction using software to eliminate the need to rely on virtual private networks (VPNs) or network address translation (NAT) tools.

    As the number of endpoints and applications they need to connect to have significantly increased, DevOps teams are finding they need to master each type of dedicated network established for endpoints ranging from mobile computing devices to internet of things (IoT). That endeavor can be cumbersome at best. NetFoundry is making the case for a programmable network overlay that allows endpoints to access applications over public internet connections securely.

    As programmable overlays become more widely available, the rate at which network operations will be incorporated into best DevOps processes is likely to increase. Network managers will continue to set up the physical underlay that enables networking; however, how applications employ that underlay increasingly will be determined by invoking a programmable overlay. A programmable network overlay also provides the benefit of further separation of duties between DevOps teams and networking professionals in a way that doesn’t require networking teams to become deeply involved in every application development project.

    That approach should reduce significantly the amount of time now required to deploy or update a distributed computing application. DevOps teams today may be able to push code into production faster than ever. However, configuring the networking services those applications require remains a set of manual tasks that have become a significant bottleneck to making IT teams more agile.

    It remains to be seen to what degree programmable network overlays will provide something of a demilitarized zone (DMZ) between DevOps teams and networking professionals. Today most networking services are provided via either directly on top of networking infrastructure or using network overlays controlled by networking teams. But it still takes days to weeks for networking professionals to respond to requests for services from DevOps teams. It’s clear the way networking services are provisioned across the enterprise needs to change substantially.

    — Mike Vizard

  • The Road Ahead for Security, DevOps Transformation

    The Road Ahead for Security, DevOps Transformation

    Qualys hosted its Qualys Security Conference 19 this week in Las Vegas. Hundreds of attendees from around the world have gathered at the Bellagio hotel to learn more about the current state of cybersecurity and what the future has in store. As you might expect, given the technology landscape today, many of the sessions and discussions have revolved around DevOps and how cybersecurity can adapt to DevOps culture.

    Scott Crawford Qualys Security Conference
    Scott Crawford, Research Vice President at 451 Research presents “The Road Ahead for Security, IT, and DevOps” at the Qualys Security Conference

    The Shifting Technology Ecosystem

    Scott Crawford, research vice president at 451 Research, opened day two of the Qualys Security Conference with his keynote, “The Road Ahead for Security, IT, and DevOps.” Crawford talked about the dramatic changes over the last decade or so—from monolithic to microservices, from standalone applications to integrated software, from Waterfall to Agile, enterprise networks to IoT / OT, from standard networks to 5G wireless, and from traditional IT to DevOps. He discussed the challenges organizations face and the dilemma of doubling down on past success and missing out on innovation.

    With all of the changes from this shifting technology ecosystem, there are consequences. Organizations no longer have a single point of control and IT teams are faced with managing and protecting an increasingly complex web of interconnected platforms, applications and services.

    Security and DevOps

    Crawford also talked about the rise of zero trust. He described it as a sort of mashup of the concept of least privileged access, combined with behavioral analytics and an on-demand, just-in-time approach to managing access. The zero trust paradigm is based on the premise of never trust, always verify—and that means determining who is requesting access, under what conditions they’re requesting access and what actions they intend to perform with that access on a case0-by-case basis.

    He shared the Xebia Labs Periodic Table of DevOps tools to illustrate the overwhelming number of options available and stressed the importance of automation. CI/CD (continuous integration/continuous deployment), RPA (robotic process automation), and SOAR (security orchestration, automation and response) solutions have been developed to help address and manage some of the complexity of both DevOps deployments and cybersecurity.

    Xebia Labs Periodic Table of DevOps Tools
    Xebia Labs Periodic Table of DevOps Tools

    DevOps and Digital Transformation

    Crawford’s keynote was followed by a presentation titled, “The DevOps Transformation of the Qualys Platform: Lessons Learned.” Dilip Bachwani, senior vice president of engineering and cloud operations for Qualys, talked about how the company has addressed the “innovator’s dilemma” and steps it has taken to deal with growing pains as it goes through its own digital transformation.

    Bachwani explained that the engineering team at Qualys has expanded exponentially in a relatively short period. That comes with several benefits in terms of how quickly they can develop and implement new solutions, but the team also faced challenges with balancing that growth and trying to maintain velocity at the same time without sacrificing stability or reliability.

    Just like every other organization going through a DevOps transformation, Qualys has had to break down silos with people, processes and tools. Bachwani explained that they needed to do things differently to automate as many functions as possible. They decided to view infrastructure and operations as software problems and find ways to fully automate deployment and configuration.

    He also emphasized that security must be built in throughout the DevOps life cycle. Qualys adopted a hub-and-spoke DevOps model and developed a robust DevOps toolchain designed to combine and orchestrate an effective set of tools for developing, delivering and maintaining software. Having a standardized toolchain ensures that there is a common platform available to everyone.

    Accelerating Transformation With Citizen Developers

    At the end of Crawford’s keynote, he talked about the lack of people with the right knowledge and skills. Cyber Security Ventures predicts that there will be 3.5 million unfilled cybersecurity jobs by 2021. That’s just cybersecurity. What about developers and other key personnel? Crawford posed the question, “Where will we find the people to do it all?”

    The answer, he said, is citizen developers. What is a citizen developer? It’s a movement to empower employees who are not developers by trade with the tools and support to implement ideas. They are the ones closest to the problem and, arguably, best equipped to understand how to solve it. They don’t need to be professional developers or need experience with coding environments. Low-code and no-code platforms give them the power to turn ideas into solutions.

    A few years ago, George Hulme wrote an article on the growing citizen developer movement. Hulme noted, “The organizations that succeed with citizen development will be those that wholeheartedly embrace the movement and cultivate it, with IT’s help and guidance.”

    The DevOps revolution isn’t going away. Companies that don’t embrace digital transformation will likely fade into oblivion as they are left in the dust by more innovative competitors, and organizations that don’t figure out how to integrate security into the fabric of their culture will struggle against a rapidly expanding and evolving threat landscape.

    At this point, these things are like the ocean tide. It is coming whether you like it or not, and it will destroy those who are not prepared. Crawford wrapped up by asking the audience to consider what their role is going to be in building and maintaining the future of DevOps and cybersecurity.

    — Tony Bradley

  • Three Ways Developers Can Worry Less About Security

    Three Ways Developers Can Worry Less About Security

    Over the past 10 years, developers have risen in organizational importance. They’ve acquired more tools, power, responsibility and autonomy. As part of that evolution, many developers today want to touch all of the layers of code and have their hands in every tool that’s being built. Known as “mechanical sympathy,” developers are taking increased initiative in areas they simply haven’t before–like installing security systems or being in charge of their team’s application security lifecycle.

    While pride of ownership is never a bad thing, in today’s complex IT environments, where organizations are adopting hybrid cloud solutions, microservices and containers–and are required to push applications and software into production as quickly as possible–this simply isn’t scalable. Pursuing mechanical sympathy in this case can be too costly and ultimately become counterproductive–especially when it comes to security, where an attacker only needs to find one vulnerability to gain a foothold in the system.

    Rather than relying on developers to become security experts, organizations should empower them to dig deep on the tasks that matter to them (development) and leverage the expertise of other specialists (security). That way, everyone can focus on their own productivity and deliver the most value to the business.

    Here are three ways developers can let go of their need for mechanical sympathy.

    Consider the Implications of Being Responsible for Security

    Taking on security means abiding by security best practices, like adopting multi-factor authentication and implementing privileged access security for secrets management. None of this is in the typical wheelhouse of the developer, and in fact, developers could actually be increasing risk if they intend on being responsible for security.

    Developers should think of it this way: Imagine something goes wrong with the application you put into production, such as leaking sensitive data based on a mistake in the source code or a design flaw. Do you really want to be the team who’s called? The answer is probably no.

    By focusing on core developer strengths and allowing security teams to handle an organization’s security strategy, developers are able to collectively ship applications that are functionally sound, as well as secure.

    Don’t Solve for Already-Solved Problems

    When it comes to DevOps methodology, there are an increasing number of tools now available that automate time-consuming security tasks–such as automated secrets management, encryption and vaulting solutions–which remove those burdens from developers and allow them to work at true velocity.

    With these tools available, there’s no need to reinvent the wheel. Developers should leverage these assets to their advantage and abstract away complexity to the security team, who should be governing and provisioning security tools so developers can get back to delivering applications to market as efficiently as possible.

    Prioritize the Value Stream

    The aforementioned tools provide a great benefit to developers–freeing them up to focus on more impactful work–but it can be easy for the opposite effect to take hold if developers get mired down in the weeds with them. Instead of trying to specialize in tools such as Kubernetes or OpenShift, which have manufactured obsolescence to begin with, developers should be encouraged to think about the big picture–creating a high-performance, automated pipeline that accelerates software delivery from code to production.

    By focusing on the health of the pipeline, rather than the specific tools within, developers establish a real-time feedback loop that enables them to anticipate the future and see the amazing projects that are truly possible. It positions them as drivers of innovation and increases their sphere of influence across the organization.

    Developers play a critical role in bringing applications and software to market with speed and stability, but when organizations default to letting them own everything from the nuts to bolts, they may end up introducing security issues that could otherwise be avoided.

    The best way to ensure security in the development process, however, is to start with a strong security foundation. Organizations that understand developers and the development process are savvier when it comes to the vulnerabilities that could be inadvertently introduced and are in a better position to secure them with minimal impact on velocity.

    In such a complex and powerful world of cloud, CI/CD and more, when developers are empowered to let go, organizations can better manage and mitigate risk, and deliver higher quality applications that drive true business impact.

    — Brian Kelly

  • What Are AWS Application Patterns?

    What Are AWS Application Patterns?

    The cloud-native approach is not just about compute power and cloud services. A “set it and forget it” attitude won’t work with cloud native; there are far too many moving pieces and there is just way too much complexity. Instead, this approach requires constant testing, optimization and improvement. This is epitomized in the two key phrases of the DevOps methodology: continuous integration and continuous delivery.

    To make this a reality, however, it takes a strategic approach to defining application patterns that will govern the way in which cloud-native applications are built and shipped, rather than a one-off effort. Since AWS is the leading cloud provider, we should discuss which application patterns are relevant to the AWS platform. There are many aspects to consider when it comes to AWS application patterns, and we will cover them here.

    Operational Excellence

    The best starting point for application patterns is a commitment to operational excellence. Typically, the term “Ops” is used to identify the IT team, but in this case, operational excellence rests on the shoulders of Dev, QA and Ops teams. In cross-functional DevOps teams, every member should strive for operational excellence at every step–even in the smallest of tasks.

    In their white paper on operational excellence, AWS encourages its users to manage operations as code. This helps avoid human error, enables automation of complex processes and allows for quick and easy rollback when errors occur. Failure, according to AWS, is an opportunity for learning. They even advise performing “pre-mortems” that try to anticipate potential points of failure before a deployment.

    AWS Trusted Advisor is a useful tool that enables this type of accountability and shared responsibility within a team. It checks and reviews your new and existing AWS workloads looking for opportunities to save costs, improve performance, tighten security or follow best practices for scaling operations.

    Security

    Security is a pattern that is non-negotiable. The term “DevOps” has inspired another variation called DevSecOps that signifies this fact. Security operations take center stage when talking about DevOps.

    The interesting thing about DevSecOps is it actually results in more freedom, flexibility and trust across teams when done right. This is unlike traditional approaches to security which created silos, stifled creativity and slowed down innovation. Security is now a key piece of the puzzle, not an afterthought. AWS has many machine learning-based security solutions such as Macie which automatically identifies and secures personally identifiable information (PII).

    Along with this, configuring role-based access controls using AWS IAM is essential to have greater control over who or which applications access data and for how long. Access Control Lists govern access to data stored in AWS S3 buckets.

    The news is full of instances of data breaches due to weak security policies and access controls. Capital One is a recent example of a data breach that affected 100 million of its users. While security in the cloud is more complex than before, AWS has the necessary tools and systems in place. It’s up to organizations to implement a security strategy that prevents misuse of their data.

    Reliability

    Today, there is a low tolerance for downtime because of the potential loss of revenue. With the stakes so high, reliability is a pattern any application custodian would have high on their list of priorities. AWS has multiple reporting and health monitoring tools to keep you constantly on the pulse of your applications.

    Architectural patterns like microservices enable better resilience by decomposing monolithic applications into more manageable chunks called services. This “divide and conquer” approach leads to higher availability, which is critical for SaaS applications.

    Patterns like chaos engineering seek to intentionally kill random instances and services and force the DevOps team to figure out workarounds and backups for every scenario.

    Application Performance

    With the explosion of data, applications are always dealing with lots of data to transfer, store and process. An application’s performance depends on three factors: the backend data storage layer, the middleware components and the frontend.

    The backend data layer is the most critical component when it comes to performance. Choosing the right storage formats, database types, storage devices and organization patterns all contribute to the speed of data access. AWS has an amazing array of storage services, including S3, RedShift, Aurora and Glacier. AWS gives its users every type of storage solution, all of which should be considered to improve data management.

    AWS is devising new ways to query large datasets without bearing the load on your existing systems. RedShift Spectrum is one example of this. It is a great way to “minimize the need to scale Redshift with a new node, which can be expensive.” If you’d still rather not have to manage any RedShift clusters on your own AWS Athena is a great serverless alternative

    That gives you all the power you need to query large datasets in S3 without having to maintain any clusters of your own.

    This pay-per-use model is making its ways across the entire AWS stack with services such as ECS and Fargate offering completely serverless experiences when operating containers at scale. What started out with AWS Lambda is catching on fast, and many AWS services like the ones mentioned above enable serverless experiences with a focus on application performance.

    Cost Optimization

    When moving to the cloud, pricing is completely different. Rather than paying for perpetual licenses, you now pay a small fee for every small resource that you use. Though small on its own, you’ll soon realize that cloud costs can shoot up easily if you’re not paying close attention to your spending.

    Cost optimization is necessary as you scale operations in the cloud. Cost optimization includes looking for more efficient services, whether that’s within the same vendor platform or a different platform. At a minimum it may require a lift-and-shift approach to transition from expensive old infrastructure to inexpensive new alternatives. For example, shifting workloads from VMs to containers to serverless within the same platform can show great cost savings, since containers and serverless are generally more cost-effective than VMs.

    It pays to leverage the expertise of experts in this area. They should ideally be people who have spent years using AWS, understand Well-Architected best practices and have found ways to cut costs and derive more value from the same budget.

    Application Patterns Enable Extensibility

    Microservice applications adopt a pluggable architecture. This enables them to be easily integrated with external applications. Typically, API-based communication patterns are most common. AWS API Gateway is a service that manages API design for AWS applications. In some cases, an SDK is the better choice–for example, when you need more control over the developer experience and integrations. It’s important to know when to choose either option.

    Application Patterns Enable Portability

    Portability is the ability to move workloads across instances without interrupting their functioning. As instances change, the workloads which they support shouldn’t be affected. This is only possible if there is a clear separation layer between the workloads and the infrastructure that runs them.

    Application Patterns Enable Shift-Left

    The DevOps methodology is known to encourage a shift-left approach to software delivery. This means that not only Dev, but also QA and Ops contribute to the design and development stage of an application. This fosters deeper collaboration across teams and breaks down silos.

    A shift-right approach holds true as well. Shift-right means developers are responsible for the code they write. They are equal owners with operations teams for the resilience of the apps they build and also the bugs they introduce into the system. This practice of putting ownership and responsibility where it belongs is very healthy for a DevOps team.

    AWS facilitates pipeline management using tools such as CodePipeline, CodeCommit and CodeDeploy. They each perform similar but complementary roles and help build a CI/CD pipeline. They make it easy to get started with CI/CD within the AWS platform.

    For organizations further down the line in their cloud journey, AWS’ pipeline management tools may seem too simplistic for something like GitOps. Instead, they’d want to look outside AWS for tools such as Jenkins X or Weave Flux which are designed with GitOps automation in mind. Whether it’s the simple or advanced route, a pipeline brings great benefits over a manual development process.

    Conclusion

    Though tools enable the implementation of helpful application patterns, on their own, they are ineffective. Application patterns need a deliberate strategy and an approach for a start. Only after a strategy is in place, can you move to deciding which tools to use. With a strong strategy in place, any of the tools mentioned here can be swapped out for other better tools and the results will be the same. It’s important to not be distracted by the next shiny tool but keep a keen focus on the strategy for implementing AWS application patterns.

    As we’ve seen here, application patterns are diverse, but they all build upon each other. Without even one of these pillars, organizations would not be able to realize the goal of cloud-native applications. On the other hand, if they give careful thought to each of these application patterns, organizations would deliver cutting-edge applications that can only get better with the passing of time.

    This sponsored article was written on behalf of Eplexity.

    — Twain Taylor

  • Survey Surfaces Uneven Approaches to DevSecOps

    Survey Surfaces Uneven Approaches to DevSecOps

    A ZeroNorth survey shows implementing DevSecOps is rife with questions for many organizations, with no clear answers

    There’s general agreement that digital business transformation initiatives are driving an overall acceleration in the rate at which applications are developed. At the same time, however, given the critical nature of those applications, cybersecurity has never been more of an imperative for DevOps teams. The challenge they are encountering is not so much a lack of tools to address that requirement, but rather a lack of clarity in terms of what tool to use when.

    A survey of 57 cybersecurity professionals conducted by ZeroNorth, a provider of a platform for orchestrating vulnerability scanning tools, highlights the extent of the DevSecOps challenge. The survey finds 63% of respondents said their organization currently employs six or more scanning tools. The most widely employed are network scanning (53%) and vulnerability scanning (51%). However, a quarter (25%) don’t know if their organization is using interactive application security testing (IAST), while 19% don’t know if they are using software composition analysis (SCA) tools.

    As far as DevSecOps is concerned, there’s little to no clarity in terms of where to primarily focus scanning efforts. Build/CI environments (68%) receive the most focus, but 46% are focused on scanning within integrated development environments (IDEs). Container/artifact management (67%), source code repositories (58%) and deployment (56%) all fall somewhere in between, the survey finds.

    There’s also no clear consensus on the merits of open source versus commercial testing tools Open source software (OSS) tools were identified as a priority for less than half of respondents (47%). However, 27% of respondents said they expect to begin using open source tools in 2020. Of the respondents currently employing OSS tools, 14% said believe these tools are more effective than commercial test and scan tools. Well over a third (39%) said they believe they are more effective when combined or customized. Just under a third (32%) said OSS tools are equally as effective as commercial options, while only 9% said they are less effective.

    The survey also shows disparity when it comes to the various areas that make up a digital business transformation, with the most mature being cloud migration (80%), followed by DevOps (67%), continuous integration/continuous delivery (CI/CD) (62%) and microservices (62%). Overall, 79% of respondents said they have a digital business initiative underway.

    ZeroNorth CTO John Steven said it’s clear that in many cases, the need for faster iterations of application development is outpacing the operational capabilities of IT organizations, especially when it comes to DevSecOps. Given the chronic shortage of cybersecurity professionals, there may be an average of only one cybersecurity professional for every 100 developers. Having cybersecurity professionals participate in every scrum session isn’t feasible, so there needs to be a way for cybersecurity professionals to provide guidance to developers specifically when it comes to what scanning tool should be applied and when, said Steven.

    The survey finds network (53%) and vulnerability (51%) scanning are the most broadly employed. However, that also suggests that many IT teams involved in digital business transformation initiatives are not making use of scanning at all.

    The good news is that survey respondents said identifying bugs, flaws and vulnerabilities throughout the software development life cycle (SDLC) is either “extremely” (58%) or “very” (42%) important to all participants involved. A total of 47% said it was either “extremely important” or “very important (35%) to improve visibility around operations by integrating security earlier into the software development life cycle (SDLC). However, while the DevSecOps spirit may be willing, the ability to implement best DevSecOps practices is still clearly weak.

    — Mike Vizard

  • Five Tips to Approach DevSecOps Training

    Five Tips to Approach DevSecOps Training

    Developers are on the front lines when it comes to protecting their organizations from cyberattacks. As we’ve seen with the hacks of Monster.com or the Fortnite vulnerability, 2019 has been a trying year for organizations who have failed to protect their applications and websites.

    With an increase of cyberthreats today, it is vital that organizations and developers incorporate standard security protocols within DevOps, a practice known as DevSecOps. Whether exploring these practices around security training, skills, metrics and more in the industry, it’s important to understand how each group fits into the security process.

    Here are five top tips for security training to successfully implement a DevSecOps strategy.

    Recognize Security is a Shared Responsibility

    Many departments throughout an organization make the mistake of thinking the responsibility of keeping their organization secure lies solely with the security department. However, with nearly 200 cyberattacks happening every hour, it’s important everyone gets on board in protecting applications and networks. As the creators behind our modern-day websites and applications, it’s especially important for developers.

    DevOps and security teams need to be taught how to approach security jointly. When approached separately, it is impossible to achieve DevSecOps. Without DevSecOps, the applications and websites used by consumers everyday will not be secure, and there could be security, quality, legal and reputational implications. Security is now being seen as a fundamental aspect of a consumer’s decision, and consumers gravitate towards brands that are more secure.

    Ensure the Entire Development Team Understands Common Cyberthreats and Application Vulnerabilities

    In today’s world, it is especially important for development and operations specialists to understand application vulnerabilities, and best practices to avoid those vulnerabilities. Without this knowledge, developers and their teams won’t understand just how important security is until it is too late.

    Staying on top of the evolving threat landscape, however, can be a daunting task. After all, there is a lot of information out there. The first step to staying informed is to compile a short list of reliable, valid security news sources. Another step could be creating an internal method for the security team to share details on new vulnerabilities with the development teams.

    Unfortunately, hackers tend to exploit vulnerabilities that were accidentally created by DevOps. In order to fight this, DevOps specialists should be made aware and trained in secure programming, secure application configurations and use of secure frameworks.

    Incorporate Just-in-Time Learning into Your Strategy

    Traditional training courses, especially in the security sector, have some challenges. Many universities and free online resources will offer courses online in cybersecurity. While this can be beneficial in continued training, it can take a significant amount of time to complete the course, and some projects require a certain level of knowledge sooner rather than later. Most courses need to be taken well in advance of a project, where the acquired knowledge will then be applied.

    For example, say developer X just started a course in how to protect from vulnerability Y. At the same time, developer X has a project with code that could be vulnerable to Y due in the next two weeks. With the tight deadline, developer X may not be able to get the knowledge they need to be able to protect their application in time.

    In order to combat this, the security industry now offers real-time learning. Otherwise known as “just-in-time learning,” this approach is giving the employees the much-needed information exactly when they need it. These courses usually come hand-in-hand with using application security testing technology, enabling rapid remediation of a detected vulnerability. For example, when a new security technology is introduced to the organization for development purposes, just-in-time learning would involve developers learning to use it on current projects in real time.

    Avoid Making DevOps Specialists into Security Experts

    While it is important for DevOps practitioners to have knowledge of security best practices, it’s important to remember they should be focusing on their task at hand: creating applications. Security transparency is a critical condition for security adoption by the DevOps team, so it is important the technologies developers rely on are transparent. However, security technologies should not distract DevOps specialists from development and operation. DevOps specialists should be security aware and applying their best security development practices.

    The technologies should test applications and get results to those who need them. DevOps practitioners should then use those results, without having to worry about learning and running sophisticated security detection and protection technologies.

    Remember the Goal is to Educate, Not Embarrass

    Even when using the above tactics, it is still quite possible developers will miss a vulnerability and SAST, DAST, IAST and SCA technologies may discover it first. When this happens, it is easy for DevOps specialists to become embarrassed because their managers see the results first. No matter the experience level, developers will likely at some point make a mistake that can cause a vulnerability–which ultimately gets back to their supervisors and peers.

    Rather than feel embarrassed over the security technologies, developers need to learn how to utilize them to their advantage. For example, modern SAST allows developers to conduct tests out of an IDE and return the test results to the same one. The developer is the only one who will see these tests, and therefore, they can be the one to review and remediate a problem. This process helps eliminate the shame developers feel, and it will instead be replaced with education, security and confidence.

    Cyberthreats are not going away, and all signs are pointing to the fact that they are only going to get more advanced in the future. However, with adequate training and cybersecurity education for development teams, organizations can stay ahead of adversaries and fortify their application security.

    — Joseph Feiman

  • Why Mobile App Security is Like a Rubik’s Cube

    Why Mobile App Security is Like a Rubik’s Cube

    Now more than ever, mobile applications are driving modern business, and developing and launching them are top priorities for companies across industries.

    As of 2018, more than 194 billion applications had been downloaded from app stores, according to Credence Research. The global mobile app market was valued at $109.67 billion in 2018 and, at the time of the report, was set to see a 15.60% compound annual growth rate during the forecast period (2019-2027), according to the firm.

    Although only a small fraction of mobile applications will be used in the enterprise, the tidal wave of mobile apps off-the-shelf, corporate-developed and sponsored creates substantial new challenges. For DevOps teams, it means they must make their internal processes more agile and efficient. That’s a good thing. But it also means they face a critical step securing those apps, which can add weeks to development times and cycles.

    One problem is mobile apps run outside of the confines of corporate networks and can access services across the public internet. This makes mobile applications a huge security vulnerability point–especially if they aren’t architected properly and configured with proper security and access controls.

    A report by WhiteHat Security offers a stark reminder that mobile apps are riddled with security flaws, many of which go unremedied. Based on 17 million application security scans carried out in 2018, the firm found a 20% increase in vulnerabilities in the applications organizations tested for security flaws. Complicating matters, most enterprises face the risks presented by the use of personal mobile devices by their employees.

    It is not uncommon for enterprise users to have 15 to more than 80 enterprise applications on their devices. Enterprise must have control over the app and the data in the app before permitting widespread deployment.

    “That simply visiting a website can lead to your iPhone being hacked silently by some unknown party is worrying enough,” said Thomas Brewster, a cybersecurity reporter for Forbes, in reference to a recent, successful hack of an iPhone. “But given that, according to Google researchers, it’s possible for the hackers to access encrypted messages on WhatsApp, iMessage, Telegram and others, the attacks undermine the security promised by those apps.”

    Challenges of Securing Mobile Apps

    Why is app security such a challenge? For one thing, securing apps before release doesn’t happen just once; every time an app or OS is updated, whether pre- or post-release, it must be secured again.

    Today, it takes an average of five weeks to secure a mobile app before launch.

    What’s more, when third-party libraries used by the app are updated, the app must be secured again. DevOps teams need to ask themselves: “How much of the time during which this app is in production will it be vulnerable to a security breach?”

    But integrating security into mobile apps gets even more complex. Here’s why: Integrating app security by manual coding is hugely time-consuming and error-prone, given that implementing cybersecurity isn’t everyone’s cup of tea. For example, a developer may not implement the data security APIs everywhere in the app, resulting in some data being written unprotected.

    And another factor tangential to security–device adoption–enters the picture. Employees expect corporate-authorized and distributed mobile apps to provide the same user friendliness as any consumer app they are accustomed to. If an app is not easy to use they will shun it, and enterprises won’t derive the business and process benefits they expect from mobility. Enterprises that attempt to secure their mobile apps may resort to forcing employees to use a managed, corporate-supplied device in order to use the app, or introduce a cumbersome VPN/login experience that will allow employees to access key data on remote servers from within the app.

    In short, such security practices, while they may secure data, make the mobile app inconvenient, cumbersome and difficult to adopt and use.

    What Can Be Done?

    Today, many of enterprises’ mobile security protocols and practices are rooted in manual methods, and DevOps and security teams struggle to place security-hardened devices and apps in production. But two practices remove virtually 100% of the issues that plague enterprise teams today.

    1. No-Code Security Integration: A no-code security integration solution can embed military-grade data encryption into apps and deliver the enterprise-level security controls that organizations need to ensure that corporate data is always safe, even when the device isn’t under enterprise controls.
    2. Securing the App, Not the Device: Securing mobile apps–not the endpoint devices or device-resident containers they run in–decomplicates security while significantly reducing security risks. This practice enables developers to automatically embed the security controls into the organization’s apps, and it enables employees to use those apps without having to deal with device security restrictions.

    What’s more, when an app or the OS behind it changes, it’s a trivial matter to re-secure the app.

    Smart users of mobile devices take precautions to safeguard their data from hackers. While that’s a prudent move, the real job starts with the DevOps and security folks to solve the security-integration Rubik’s Cube once and for all.

    — Nikfar Khaleeli

  • Kubernetes and Service Mesh With StackRox

    Kubernetes and Service Mesh With StackRox

    DevOps and Kubernetes enable organizations to “go with security,” adding security to the code instead of on top of it. In other words, security is built-in rather than bolted on.

    This is one of the aspects of security in the DevOps world with a Kubernetes system that Ali Golshan, co-founder and CTO of StackRox, explained during this exclusive interview with Alan Shimel, Media Ops CEO and editor in chief. The other aspect is security has become continuous instead of snapshots, which provides “a lot more visibility into various stages, various deployments, as well as running environments,” he said.

    During the interview, he explored containers, orchestrations, Kubernetes and service mesh.

    “Leveraging this cloud-native infrastructure, Kube and service mesh the right way reduces your dependency on third-party tools, allows you to hand off things you typically handed off to vendors and does that inside your infrastructure, which makes it actually more secure and highly scalable,” said Golshan. “You can automate that and reduce your lock-in and your sort of dependency.”

    Check out the interview below to learn more about the best and emerging practices in Kubernetes, service mesh and the security feedback loop.

    — Veronica Haggar