devopsy.kinsta.cloud

Tag: devsecops

  • The DevOps Security Stack

    The DevOps Security Stack

    The whole idea behind DevOps is automation. DevOps automates the development process by eliminating or minimizing human error. If an error occurs, the applications fail quickly so the errors can be resolved promptly on a smaller scale. DevOps and cloud-native applications complement each other perfectly.

    Even though DevOps offers a more efficient and faster way to develop and deploy applications, security remains an issue. On paper, DevOps and cloud-native applications might be more secure than their traditional counterparts, but the reality is not that simple. With the newer, more complex, highly distributed infrastructures common to DevOps come new challenges that need to be identified and addressed.

    This article walks through those challenges to highlight what it takes to secure a DevOps workflow. I won’t focus on specific tools because DevOps is not about specific tools; rather, I’ll focus on the components of DevOps workflows that present special security challenges and explain how to address them.

    The Vulnerabilities You Just Can’t Ignore

    1. Careless use of recycled code

    One way DevOps improves developer productivity is by letting developers recycle code from previous projects or open source repositories such as GitHub. But without proper screening and sanitization, these pieces of code can pose threats to an application.

    1. Multiple platforms make the attack surface larger

    When deploying code in the cloud, you can’t use traditional security services. You need to rethink your security strategy. DevOps teams leverage various platforms, from serverless computing to microservices to multi-cloud in their applications. There’s no single solution to secure cloud-native applications. These applications are highly distributed and have various components, so organizations need a multifaceted approach to better secure these applications.

    1. The dynamic nature of cloud-native applications doesn’t help

    Cloud-native applications are continuously integrated and deployed, which makes it difficult for security teams to identify and mitigate risks. Traditional security tools can’t match the sheer velocity, scale and dynamics of cloud-native applications, leaving them useless.

    1. Secrets need to be secured

    When following the DevOps approach, security professionals need to create privileged accounts and login details and share them over business networks automatically. With serverless applications and the cloud, security teams don’t have a traditional location such as the operating system to execute security policies. A host of useful data, such as keys, storage account credentials, secrets, database passwords and embedded passwords, are stored in repositories. It’s crucial this data is kept extremely secure, as attackers can use this information to cause some serious damage.

    1. Containers can leave your applications more vulnerable

    Since the microservice approach involves a distributed infrastructure, it exposes your system to the network, which makes it easy for attackers to sneak into the system. Containers can be spread across different systems, which makes the threat landscape even larger. Containers are highly replicable, so if there is a vulnerability in one microservice, it can get replicated every time the source code is used.

    Using open source software in containers can make way for an increase in vulnerabilities. DevOps teams should make sure unauthorized containers are not used in production. These containers can be used by attackers to launch an attack on the entire application.

    1. Hosts aren’t automatically safe

    Even if containers are properly secured, the hosts they run on are vulnerable to new threats and day-zero attacks. Container runtime should be up-to-date to avoid risks that can lead to container escape. This can help attackers to take control not only of a container but also the host operating system. So, it is important that hosts are given appropriate protection.

    1. Kubernetes clusters need additional security

    Kubernetes is a widely accepted container orchestration platform. However, it’s difficult for security to be enabled at multiple layers. Kubernetes uses APIs to manage containers, and recently, it was discovered that K8’s API server is quite susceptible to attacks—attackers can make use of the API server to perform malicious activities or install malware in the application.

    Running multiple workloads on one cluster is not a good idea. Sensitive workloads should be run on a dedicated set of machines to avoid attacks through less secure neighboring applications. There’s also a need to secure sensitive metadata, which can be stolen and used to change privileges in a cluster, thereby paving the way for unauthorized changes in an application.

    DevSecOps: The Future of DevOps Security

    In traditional applications, security holds less priority, and security policies are always employed after development is completed. But with DevOps, security can’t be an afterthought. Companies depending on the DevOps approach need to make security their top priority. One of the ways to make sure security is in the foundation of a DevOps implementation is a DevOps security stack. To employ the DevOps security stack, IT teams no longer should be walled off from the DevOps team.

    Security experts’ involvement can help them gain insights into what the application is and how it’s supposed to function so they can identify risks and take steps to mitigate them. This DevSecOps approach has become popular. DevSecOps is a collaboration between the development, security and operations teams who work together to ensure security is at the root of an application, not just on the surface.

    Symantec Cloud Workload Protection: A Modern Solution for Modern Problems

    Most organizations use hybrid cloud storage comprised of workloads distributed among public clouds, private clouds and on-premises, which can lead to an increased attack surface and vulnerabilities.

    Symantec Cloud Workload Protection (CWP) helps organizations monitor and protect their workloads, no matter where they reside. With CWP, organizations don’t have to look for multiple products to meet their many security needs. CWP offers a single console to monitor and manage security across various platforms. It offers automatic discovery of workloads across AWS, Azure and Google Cloud, and visibility into security postures and software, which enables automatic workload monitoring and protection. With continuous delivery workflows and malware prevention, CWP is essential for modern software development.

    Sign up for a free trial of CWP.

    — Twain Taylor

  • Shift Left Without Fear: The Role of Security in Enabling DevOps

    Shift Left Without Fear: The Role of Security in Enabling DevOps

    It’s the age of DevOps, and we all want to shift left, which refers to the idea of performing processes earlier in the CI/CD cycle. That includes security checks and audits. By starting security operations earlier in the delivery pipeline, it becomes easier to find problems, and teams have more time to address them before pushing code into production.

    The challenge, of course, is building a shift-left security operation that allows you to perform security operations early without slowing down delivery speed. Let’s take a look at how to square that circle.

    Defining Shift-Left Security

    A popular term in DevOps culture is “shift left.” But what does shift left mean? Shifting left refers to the effort by a DevOps team to implement measures to ensure application quality at an early point in the software development life cycle. In the case of application security, this means implementing measures to ensure security concerns are taken into consideration while the application is being developed, rather than at the end of the process.

    The overall goal of shift-left security is to identify and resolve potential vulnerabilities earlier in the development life cycle, when these issues are less expensive to fix. Doing so will help to mitigate the risk potential security concerns pose to both the delivery schedule and your end -users.

    DevSecOps: Integrating Security Into the Development Process

    Let’s be honest: Faster and more frequent development cycles aren’t going away. Slowing delivery speed to analyze and bulletproof the application at the end of the development process is no longer a viable format for implementing security. DevOps and CI/CD need to be embraced and enabled by the security staff.

    For security teams to enable the DevOps process, collaboration is key. Through this collaboration, the process of DevOps transforms into something known as DevSecOps. In DevSecOps, security personnel work closely with the rest of the DevOps organization to help those who create and deliver the application to gain a better understanding of what is needed to address security concerns as early in the development life cycle as possible.

    The following tips serve as a jumping-off point for implementing this collaboration:

    • Make security the responsibility of the entire DevOps team: Impress upon the development and operations staff that security is now the responsibility of the entire organization. Simply addressing potential vulnerabilities post-development will eat up too much time and increase the risk that something will be missed. Buying into this process is an essential part of implementing successful collaboration between the security team and the rest of the organization. An example of this would be impressing upon developers to code with security in mind.
    • Facilitate regular discussions about application security throughout the development process: It is the responsibility of the security folks to keep security considerations at the forefront of a developer’s mind while they develop new features. Use the agile process to your advantage. Backlog meetings can involve security folks to ensure the creation of user stories includes consideration for security concerns. Your daily standup meetings are another place to include security personnel. This will provide security staff with an opportunity to speak up when the work described by the developer requires—or might require—considerations related to security that have yet to be addressed. Doing so will help to ensure the ball is not dropped, allowing for potential issues to be rectified before they even exist.
    • Use test automation and continuous integration to your advantage: When it comes to addressing security concerns throughout the development process, continuous testing is your best friend. And, in cases where it makes sense, the DevOps team should integrate automated test scripts for the detection of security and into their continuous integration process. Such tests can include developer-written scripts to test for vulnerabilities in the code base and tools for static code analysis. Another part of your continuous testing strategy could involve the use of tools for infrastructure monitoring.

    The data produced by these strategies can then be analyzed by security folks. And from this analysis, recommendations can be made to the DevOps team regarding the path forward to close potential gaps in security before they ever reach production and can be exploited.

    Understanding the Role of Security Personnel in the Development Process

    Security folks are often not coders, and development personnel are often not security experts. And while it may be frustrating at times, the solution to managing this disconnect is in the collaboration described above. Situations will arise where developers need to develop with various technologies to build a quality product. It’s possible that these technologies will lend themselves to security concerns that require security expertise. The job of security personnel shouldn’t always be to fight back against the use of these technologies. The security team should act as facilitators—take what development and operations staff intend to do and foresee the potential impacts that innovation will have on security—then take these potential impacts and provide insight into what needs to be done to reduce the risks.

    Conclusion

    In the past, security often was considered as an afterthought in the development of an application and its infrastructure. The movement toward faster development cycles and more frequent application releases has forced development organizations to think about security differently. Nowadays, so much can change in an application in a short time. This has forced DevOps organizations to integrate security into the development pipeline to make security a continuous consideration in the development life cycle. With this integration, the responsibilities of security personnel have shifted. Security teams now need to be enablers of the DevOps culture, empowering DevOps processes with security in mind.

    To see how Symantec CWA can help you shift left without fear, sign up for a free trial to see how it can help secure your cloud.

    — Scott Fitzpatrick

  • Open Innovation Labs: How Lockheed Brought Better Security to Fighter Jets

    Open Innovation Labs: How Lockheed Brought Better Security to Fighter Jets

    How Red Hat’s Open Innovation Labs have helped accelerate Lockheed’s software development for the F-22 Raptor

    As the key government contractor charged with helping the U.S. Air Force keep its F-22 Raptor jets in fighting trim, Lockheed Martin Aeronautics increasingly values software delivery speed as much as engine speed. So much of the continued evolution of these fighter jets depends upon continual upgrades of the software code powering all of the physical systems built into them, from tip to tail.

    Until a year ago, these jets, which first rolled out of the manufacturing plant in the 1990s, were supported by the waterfall development methods of that same era. Lockheed executives and Air Force brass recognized that the F-22 needed a DevSecOps transformation, and fast.

    “When you have a world-renowned platform like the F-22 Raptor, adversaries are constantly looking for ways to counter it,” said Michael Cawood, vice president of F-16/F-22 product development at Lockheed Martin. “This means we must constantly add capabilities and improve the F-22. And we must do it faster than ever before. We needed to transform our own organization and how we did things.”

    To accelerate that process, Lockheed last year sent a small contingent of engineers through a residency program at the Red Hat Open Innovation Labs to fast-track the process of implementing an open source architecture onboard the F-22 while adopting agile development methodologies and DevSecOps practices. Since bringing back their learning to the organization, these engineers helped to catalyze a faster development process that has helped Lockheed introduce software features for the F-22 years ahead of schedule.

    How Open Innovation Labs Works

    Now in their third year of operations, the Open Innovation Labs were developed by Red Hat as immersive training grounds to help its enterprise customers figure out how to deliver better software, faster. A standard engagement has companies such as Lockheed pay for residency for anywhere between three to six developers and operations staff to get paired one to one with Red Hat employees—engineers, consultants and others—with deep knowledge in DevOps and agile development. They work with them in a time-boxed four- to 12-week engagement to build out application prototypes using DevSecOps practices along the way. The residents are also teamed with a designer and an engagement lead who doubles as an agile coach, typically working with the customer’s product owner for the prototype.

    Obviously, Red Hat has a vested interest in training these people in technology such as its OpenShift Container Platform, getting them up to speed on how to orchestrate and manage containers and microservices. But the labs approach is in a different league than the standard vendor training program. It more closely follows the DevOps dojo model that enterprises like Target and Capital One are running internally to scale up cultural and process transformations across their IT organizations. Like those dojos, the working model is to build real software through a guided learning process that helps participants get hands-on experience in how to change the way they deliver software.

    Red Hat runs the labs either out of a handful of dedicated spaces it runs around the world or within pop-up labs of the customer’s choosing. Besides Lockheed, other notable alumni include the likes of Volkswagen, UNICEF and Heritage Bank. According to a recent analysis by Forrester Consulting, participants in the Open Innovation Labs program are accelerating application development by more than 60%.

    Lockheed’s Accelerated DevSecOps Transformation

    In Lockheed’s engagement with the Open Innovation Labs, the organization sent out a cross-functional team of five developers, two operators and a product owner. They were tasked with building out a new application for the F-22 on OpenShift, using that process as a model for future development workflows. As a part of the process, Lockheed also worked with the labs to help it build out an internal dojo that could facilitate the scale-out of the knowledge gained by its small team across the entire F-22 development team. Six months after the initial residency, Lockheed managed to scale its OpenShift deployment and DevSecOps transformation across its entire 100-person team.

    “By working with the Red Hat Open Innovation Labs team, we changed everything—our toolchain, our process and, most importantly, our culture,” explained Cawood.

    As a result, the F-22 development organization has been able improve its ability to forecast for future sprints by 40%. More importantly, it has cut what was once an onerous five- to seven-year process of rolling out new software capabilities for the aircraft. Lockheed is on track to deliver new communications capabilities for the F-22 this summer a full three years ahead of schedule.

    — Ericka Chickowski

  • Security: Are You Doing DevOps Right?

    Security: Are You Doing DevOps Right?

    Phil Kernick, co-founder and CTO of cybersecurity specialist CQR Consulting, has no fundamental problem with DevOps, but asks, from a security perspective, “How many people do it right?”

    If DevOps is going to work and produce secure systems, then developers must take responsibility for security. It’s not something that can be treated as an additional process.

    But abstract responsibility isn’t sufficient. It’s rare for developers to have security tools in their kit and an understanding of their results, said Kernick.

    Learn From History

    As former systems administrator and past president of the Systems Administrators Guild of Australia (SAGE-AU, now the Information Technology Professionals Association), Kernick suggested that DevOps pretends that the discipline of systems administration does not exist and merely treats infrastructure as if it were a software library.

    Spinning up an instance is easy, but do you know that it is properly designed and maintained? This is a real concern, given the number of people working as developers without professional training, Kernick explained.

    Repeatable loops and short development cycles do make sense. But are you confident all the individual pieces being assembled were built properly?

    That raises questions about the software supply chain. Where did that Docker container actually come from? Is it well-maintained?

    The process needs to be managed, yet, people at some organizations are “just grabbing things from anywhere,” Kernick said.

    “It almost integrates the ‘not my problem’ attitude with development,” he noted.

    Developers tend to care about whether a component works from a functional perspective, but an untrustworthy piece of code will compile and run.

    Developers working in a DevOps environment need to understand the tools that help ensure code is secure, and they need to understand infrastructure, said Kernick.

    ‘Code Reuse is Bug Reuse’

    DevOps makes the old joke that “code reuse is bug reuse” even worse, said Kernick, citing the example of a piece of vulnerable code shared on the Stack Overflow site and reused more than 100,000 times in GitHub-resident projects.

    “I don’t want DevOps running in my bank,” he said. What he does want is well-engineered, secure, well-run, certified software.

    Sacrificing security might save some time and get a new product on the market sooner, which might be acceptable if there are no real risks to the user.

    It is easy to tell if a system is really important, as it involves tradable value, safety or privacy. Obvious areas include banking and health. Similarly, it is clear that a website that allows access without requiring any credentials is unimportant.

    But there’s a wide middle ground where it’s “really hard” to determine a system’s importance because it is so difficult to imagine how criminals might exploit it.

    For example, Kernick once bought a DVD cataloging app to help avoid duplicating items already in his very extensive collection. He thought this fell into the “unimportant” category. But—fortunately, as it turned out—he took the usual precaution of using a unique password for the associated service. Sometime later, he received a sextortion email that proffered that password as supposed proof that the criminal had gained control of his computer.

    Worryingly, when he told the developer what had happened, it did not accept that there was a problem. The company said the password quoted in the malicious email wasn’t his password for the service—proving in the process that it was storing passwords in plain text!—even though he explained he changed his password as soon as he received the message. Predictably, he uninstalled the app.

    Clearly, Kernick didn’t know what development methodologies that company used, but that’s not the point. The anecdote shows that a seemingly unimportant system can quickly become important to the user in situations outside the developer’s control. Consequently, security is always important.

    DevOps and Security

    He suggests that as long as an organization has the right security and governance processes in place, it won’t matter what development methodologies are used. So it can safely adopt DevOps or whatever else is most efficient in the circumstances.

    It is possible to use DevOps practices to achieve speed without sacrificing security, Kernick said. But to do that, organizations need to take advantage of advances in software development without throwing away hard-won security experience.

    — Stephen Withers

  • Motorola Solutions: Driving a Thriving Security Culture

    Motorola Solutions: Driving a Thriving Security Culture

    It’s crunch time in the cybersecurity industry. For too long, many companies have remained unmoved by the increasing threat of cyberattacks, despite increased digitization of their products and services. Customer data is the new gold, and some organizations are leaving the door to their vault wide open.

    In saying that, secure development is complex and not without its challenges, especially at scale. In my experience, it is an uphill battle to win over developers on secure coding and best practices. In the mind of a busy programmer working to achieve strict delivery deadlines, security is not a priority over feature development and function—it is instead seen as a tedious task that interrupts their creative flow. However, if we are going to ready ourselves in the battle against those who seek to do harm, this culture needs to change.

    Marilyn Barrios is the senior cybersecurity training manager at Motorola Solutions, running the security training program for its team of more than 6,000 developers across the globe. Her goal is to ensure that those on the front lines of the company’s extensive software development are equipped with the knowledge, tools and ongoing training required to combat the growing global cybersecurity threat.

    To accomplish this, Barrios created an impressive internal security culture, one that thrived not only from a core skills perspective, but also in understanding its paramount importance in overall software quality. Her people-first, positive approach engaged the development team, created excitement about security and morphed into something far more powerful than a simple compliance exercise.

    “Ensuring that our products are secure is our highest priority. That’s why we’re working to create a culture of security-first thinking across the company—so people not only understand cybersecurity and why it is vital to maintaining a high standard of software quality, but are also excited to learn more,” she said.

    With such a large development team covering multiple facets of the business, insight into each individual’s security knowledge and current skill level could be elusive and difficult to collate. Barrios sought to streamline this process, working toward a holistic solution that would deliver key metrics and relevant training in the languages and frameworks that were actively being used in the business while remaining engaging enough to be revisited—even for more senior engineers.

    Marilyn and her team worked to implement an immersive, engaging training experience for their developers. Starting with a boot camp run by security superstar Jim Manico, the developers learned offensive coding techniques before playing in tournaments to test their defensive skills against the attacks they had just seen in action. This setup proved effective and eye-opening for the participants.

    “In really diving deep into how cyberattacks can be executed, the team saw how easy it was to do a lot of damage at the application level,” Barrios noted. “By then practicing how they can defend against these attacks, developers’ eyes were opened to how they can help if they keep security a priority in their work. They enjoyed the experience and it was also beneficial for them.”

    I was proud to see how well she and her team at Motorola Solutions executed a comprehensive, engaging and fun security training program that not only lifted security awareness IQ overall, but also helped to identify a new group of champions to keep the critical message of cybersecurity best practices thriving long-term within the organization.

    It was also interesting to learn that the eventual winner of the tournament did not start the program as the most experienced and security-aware developer. The boot camp was instrumental in rapidly upskilling the individual, and the gamified aspect of the training ensured a high level of engagement and information retention.

    “Our eventual tournament winner was so excited with the boot camp, and he was so engaged with the training tool. He practiced so much in a two-month period, improving so significantly, that he ended up winning the tournament,” Barrios said. “From there, he recruited even more champions, piqued their interest in security and helped them along to become advocates in their respective groups.”

    Barrios’ broader goal of creating a strong buzz that encourages an organic security culture to grow within the company is certainly on track.

    Gamified training, team events driven by tournament initiatives and the incentive to keep engaging with AppSec have resulted in something very positive: Developers not only are working to have a better understanding of security, but also actively seek to uphold company best practice initiatives day to day.

    Motorola Solutions saw measurable improvement when using tools and training compatible with the creative, problem-solving mindset of many developers, enjoying a training participation rate of more than 90%, with security accuracy increasing 24% across the global tournament that followed. Its internal security champion program has also seen immense support, growing by more than 1000% in the last 18 months. The company currently boasts 173 champions across its various product lines and will double that again over the next year. It has set a goal of at least one champion per scrum team—an initiative that holds incredible value in continuing momentum and spreading positive security influence across the organization.

    Driving a positive security culture takes time, planning and dedication, but alongside the right tools and training, Barrios’ advice is a sound reminder that clear goals and communication are powerful in achieving widespread support and change: “Always tie objectives to the ‘why.’ You should know why you’re trying to meet a goal or influence change; don’t just give a direction with no context.

    “For us, it’s easy: we make it personal. Motorola Solutions is responsible for delivering key communications over mission-critical infrastructure and devices for public safety and commercial enterprises. First responders, citizens and front-line workers alike are relying on this technology to be as secure as possible, so we emphasize the importance of learning best practices,” she said.

    With every other day seemingly bringing bad news about the latest large-scale data breach, it is refreshing to see an organization with a highly successful security program—one that can only get stronger as its developers continue to train and become the security superheroes we need to protect our digital world.

    — Pieter Danhieux

  • DevSecOps: Can JIT PAM Bring Relief?

    DevSecOps: Can JIT PAM Bring Relief?

    IT and cybersecurity leaders have come to agree that the purpose and intent of DevSecOps is to create a mindset that “everyone is responsible for security,” while also incorporating application and infrastructure security directly into the software development and delivery process. DevSecOps has proven to be a critical ideology for cybersecurity, yet is littered with false starts and failures. Many of those failures can be attributed to a basic misunderstanding, wherein IT management has come to use the terms DevSecOps and DevOps interchangeably, because of the false belief that security is already part of the DevOps process.

    A recent CyberArk DevOps Survey polled respondents to determine if DevOps and security teams were integrated, less than half of the respondents said yes. What’s more, almost three-quarters said they had no privileged account security strategy for DevOps and some 99% failed to identify all of the different places privileged accounts or secrets could exist in a DevOps environment. The survey demonstrates that common and well-established security practices have not been adopted by DevOps teams. Clearly, DevOps and DevSecOps are not synonymous.

    A clear vision of what DevSecOps should be about can lead to DevOps teams releasing vulnerable software and exposing enterprises to unnecessary risk—a problem that has been manifesting itself in the rush to embrace digital transformation and re-engineer legacy apps into cloud-based equivalents. Expediency combined with a lack of understanding increases risk, which should cause alarm.

    For the most part, breaches occur because of a lack of privilege management, In other words, proper security practices dictate the who, how and when of access, along with the permissions associated with that access. It is a concept that has given birth to platforms that manage privileges, also known as privileged access management (PAM) solutions. For DevSecOps to succeed, the concept of privilege must be embraced. However there is more to security than just privilege management; namely, the context of privilege must be incorporated, such as the “why,” “when,” and “where” of access.

    Simply put, administrators and managers often forget to revoke the rights of temporary workers, contractors and other non-employees when a project is complete. It’s an issue that plagues many DevOps teams that rely on freelancers to help move the processes forward. The lesson here is one of instituting better controls and policies, which ultimately can be adopted throughout the enterprise to bring better cybersecurity to fruition.

    JIT PAM to the DevSecOps Rescue?

    Better control over privileges has created a new acronym, JIT (just in time), that takes residence in front of the PAM acronym. The concept of JIT PAM, which is being promoted by security vendors such as Beyond Trust, is one of controlling access based upon a number of different policies that are further enhanced with behavioral data.

    At the recent Beyond Trust partner summit, cybersecurity expert Derek Smith noted, “Privileged credentials exist everywhere and 100% of all advanced attacks rely on exploits of privileged credentials.” That’s a sobering thought for those in charge of cybersecurity and those who are part of the DevSecOps process. Smith said some of the best practices around PAM include, “Track and secure, govern and control, and record and audit,” exemplifying the need for a platform approach. For Beyond Trust, that means creating a platform that defines a new paradigm of trust, one that builds policy around the who,what,why,where,when of access.

    The concept offers valuable lessons to DevSecOps team members, lessons that entail incorporating the proper security elements into the application and infrastructure layers of service delivery. For the short term, those capabilities may be beyond those in the DevOps arena, meaning that they may have to turn to third-party platforms to bring forth better security. On the plus side, JIT PAM can also be used to secure legacy applications, giving DevSecOps teams more breathing room to define and re-engineer those legacy applications as they transition to the cloud.

    — Frank Ohlhorst

  • Guess Who’s Coming to JFrog swampUP?

    Guess Who’s Coming to JFrog swampUP?

    The annual DevOps gathering and JFrog user conference, swampUP 2019, is going to be here before we know it. It’s happening June 17-19 in San Francisco, providing easy access for everyone (it’s just 30 minutes away from SFO airport).

    What’s swampUP? For the thriving DevOps community, swampUP is the must-attend event where developers, engineers and business leaders from top companies and industries network and share best practices for software delivery success.

    While conference promotions can certainly be full of fluffy cheerleading at times, one thing I’m especially excited about is this year’s swampUP guest keynote speaker, Dr. Nicole Forsgren.

    Dr. Forsgren, described as “snarky” by Forbes—a label she readily owns, if you ask—is the co-founder of DevOps Research and Assessment (DORA), which was recently acquired by Google Cloud. DORA quantified customers’ unique needs and DevOps processes to deliver custom paths to DevOps growth.

    Coming to swampUP as herself—not that she could come any other way, but not as a representative of Google—to talk about her unique research and the overall landscape. She’s planning on covering many of today’s hot topics, including DevSecOps, cloud and hybrid, tooling trends and DevOps culture in a special keynote aptly titled, “DevOps: It Only Works When You Do it Right.”

    If you don’t know Forsgren or haven’t seen her speak, her style and unique perspective perfectly blend data and statistics with understanding of realities that companies face. A bit about her specifically: Forsgren is co-founder, CEO and chief scientist at DORA. She is best known for her work measuring the technology process and as the lead investigator on the largest DevOps studies to date. She has been a professor, sysadmin and performance engineer. Her work has been published in several peer-reviewed journals. Nicole earned her PhD in management information systems from the University of Arizona, and is a research affiliate at Clemson University and Florida International University.

    Once attendees get knowledge laid on them from Forsgren, there are some intriguing sessions available in the recently released full swampUP agenda around Cloud Native DevOps, Enterprise DevOps, DevSecOps and even some really cool-looking stuff around IoT. While this may be a JFrog user conference, there are some heavy hitters involved that make this a holistic DevOps gathering, including Andy Glover of Netflix, Aaron Schlesinger of Microsoft, Jayne Groll of the DevOps Institute, Carl Quinn of Zoox, Seth Vargo of Google, Jessica Deen of Azure and John Willis of Botchagalupe, among many other powerhouse speakers.

    Of course, you’ll also see the expected lineup of JFrog experts, staff and visionaries swampUP attendees have come to know, including JFrog co-founder and CEO Shlomi Ben Haim, co-founder and CTO Yoav Landman, co-founder and chief data scientist Fred Simon, CPO Dror Bereznitsky, VP of business development Kit Merker and many more. There will be a few special additions this year, including former CEO of recently acquired Shippable Avi Cavale and JFrog VP of technology Ido Green.

    From hands-on training to inspiring keynotes and practical technical breakout sessions, swampUp is seen by alums as a premier opportunity to learn about DevOps, DevSecOps and cloud-native delivery. There’s also a full day of training and certifications for practitioners of all levels to take advantage of!

    Click here to register and join JFrog and the DevOps community at swampUP 2019.

    — Jens Eckels

  • DevOps and Security: Be Ready to Shield Your Application

    DevOps and Security: Be Ready to Shield Your Application

    All of us have heard of continuous improvement/continuous delivery (CI/CD). There are many benefits to implementing CI/CD, as it helps seamless integration from end to end for development and deployment processes. CI/CD helps in rapid improvement, shorter release cycles and more, but it also helps with the challenge of handling security effectively at DevOps speed.

    Tools for Securing DevOps

    There are thousands of DevOps security tools available in the market that help us at HCL Technologies secure our software development at various stages of the CI/CD pipeline. There are new vulnerabilities rolling out daily, and so we must be alert and keep our applications safe and future-ready.

    These are the DevOps security tools we use (most tools are open source with an option of enterprise edition):

    1. OWASP SonarQube
    2. OWASP ZAP
    3. OWASP Dependency-Check
    4. OWASP Glue
    5. Anchore
    6. Clair-CoreOS
    7. FOSSA
    8. Cyberark Conjur

    Our DevOps Toolchain Diagram

    Securing CI/CD

    Let’s consider a job in which we check out the code from GitLab/GitHub with auto-commit (a Jenkins job will be triggered as soon as the developer makes any changes in the code). You can refer to this link for  more information about Jenkins GitLab automation.

    Now, in Jenkins, we can run a security test and present it in the form of reports and dashboard to meet our needs. To get started, we can use OWASP SonarQube for static analysis. OWASP SonarQube includes found bugs, PMD and several security plugins bundled out of the box. Next, for dynamic analysis and penetration testing, we can use OWASP ZAP, which presents reports in XML/HTML format that can be used to create Jira issues.

    In the above scenario, we can also use ZAP through custom tools integration. In our case, we have installed ZAP on our local machine. We can also use OWASP ZAP installed in a remote machine.

    Steps for Remote OWASP ZAP Connection

    Windows Command: C:Program FilesOWASPZed Attack Proxy>zap.bat -config api.disablekey=true -config api.addrs.addr.name=.* -config api.addrs.addr.regex=true

    Linux Command: Zed Attack Proxy>zap.sh -config api.disablekey=true -config api.addrs.addr.name=.* -config api.addrs.addr.regex=true

    OWASP Configuration in Jenkins

    The reports will be generated in .xml and .html format. Now, with the reports generated by ZAP, we developed a Java program to create Jira issues for every vulnerability detected and assign it to the concerned person.

    Next, we have OWASP Dependency-Check analysis on our project. To configure for Jenkins, follow these steps:

    First, we need the OWASP dependency-check plug-in (which I have already installed). This process may take several minutes, as it downloads from NVD server.

    Here are the next steps:

    Alternatively, we can use the OWASP Glue plug-in, which runs OWASP ZAP, OWASP Dependency-Check and other security automated tests.

    We have also used FOSSA in our projects for license audits and vulnerability management for OS dependencies. We can use FOSSA as on-premises, but it is available only for use on Ubuntu machines.

    At HCL, we are currently working on container security with Anchore and Clair-CoreOS. We have also integrated identity access management (IAM) to our CI/CD jobs. As for IAM, we are working on CyberArk Conjur and HashiCorp Vault.

    CyberArk Conjur

    The Conjur Jenkins credentials plug-in:

    HashiCorp Vault

    Conclusion

    I have worked on various tools for security with DevOps. Below is a quick comparison of the tools that can be used for application security.

    Now that you have an idea of which tools to use, embrace security instead of worrying about it. DevSecOps can help improve and increase the outcome and effectiveness of any organization.

    — Debarghya Pandit

  • 5 Practical Ways to Deliver Secure Software That Could Actually Work

    5 Practical Ways to Deliver Secure Software That Could Actually Work

    Almost every aspect of modern life is dependent on technology. As technology becomes even more advanced and pervasive, so, too, does the need for secure software.

    Today, even the tiniest breach at an organization could result in major loss of sensitive data. Therefore, it is crucial for both the reputation and proper functioning of the organization to have steady security measures in place.

    Below are five practical ways organizations can deliver secure software by prioritizing safety and maintaining a sustainable “security culture.”

    Organizations Build and Foster a Healthy Security Culture

    A security culture, just like any other culture, thrives when it is used actively. Effective security culture is a one-time investment that can reap major benefits. However, it requires effort from the organization.

    A viable security culture is based on four key features:

    • The security culture is disruptive in nature and brings about immediate change.
    • Security practices employed by the organization are engaging for everyone, not just the security department.
    • A proper reward system is in place for the people who actively take part in security regimens.
    • Investments made into the security culture are returned in one form or another.

    Ensuring that a proper security culture is in place takes care of the biggest problem in the development of software—humans.

    The establishment of a robust security culture helps humans in an organization more than it does the computers. It provides a proper framework through which employees at an organization can act to maximize security.

    Some ways to develop the security culture at an organization include:

    • Instill the belief into the employees that security-related issues are not just the headache of the security department; rather, the whole organization should work together to resolve them.
    • Focus on spreading awareness throughout the organization by providing employees the basic security knowledge.
    • Provide opportunities for advancements in security to team members who are more excited.

    Despite having a strong security culture in place, however, breaches may happen. A proper security culture can help the organization recover more swiftly.

    Acquire a Secure Developmental Life Cycle

    A secure developmental life cycle (SDL) provides a firm foundation to monitor the security practices in an organization.

    An SDL performs essential functions such as threat modeling, security analysis and requirements, and carries out security testing. The organization that acquires the SDL agrees to an in-depth study of their security on all the software and system releases.

    Microsoft, for example, offers a free SDL that consists of security practices that could help organizations regardless of their size or platform. This is especially useful to those organizations that have just started.

    Other benefits of having an SDL are:

    • Detects bugs in the software earlier in the development cycle, which is cost-effective.
    • Safeguards the interests of the stakeholders and investors, as it makes the business secure.

    Overall, an SDL minimizes the risks that an organization faces and helps in advancing it.

    Integrate Security Tests Into the Developmental Phase

    Organizations should introduce security tests in the developmental period; that is, when the code is being written or when the programmers check in on their codes.

    The introduction of security tests allows developers to correct their mistakes at an early stage, which effectively reduces the cost of resolving the problem. Developers actively get feedback, enabling them to design software with a smaller number of flaws.

    Moreover, tests conducted at the developmental stage save time and keep the disruption caused by the whole developmental process to a minimum.

    Have a Deep Understanding of What’s in Your Software

    Developers should work with security experts to understand the software and the applications installed.

    Knowing what constitutes applications—especially open source applications—is pivotal in patching any discrepancies that may arise.

    Along with a firm grasp on the software, developers must be aware of application security.

    Application security, or AppSec, teaches advanced lessons to the testers and developers within an organization and aids them in building secure products and services.

    Encourage Mentorship

    No security system is complete without a set of security experts who can train developers in specific methods and procedures. These mentors can be responsible for conducting security tests and furthering the advancement of secure software in an organization.

    Mentors can also provide a learning experience to the staff members and go the extra mile to make sure security is accessible for everyone.

    Conclusion

    Organizations need to maintain a standardized way of delivering software. The threats we face today, if  not dealt with, can have dire consequences.

    However, the solution starts at the very beginning and needs to be integrated into everything related to software, from education to the way employees interact with each other in the workplace. Only then can we rest easy knowing our software and data are protected.

    — Zehra Ali

  • How to Design DevSecOps Compliance Processes to Free Up Developer Resources

    How to Design DevSecOps Compliance Processes to Free Up Developer Resources

    Anything that gets rolled out quickly in the technological world is a major step forward—as long as it doesn’t compromise security.

    DevSecOps is able to provide compliance processes far more effectively than before, and without jeopardizing security while also freeing up developer resources.

    How do you direct your IT team to keep your applications and customers safe without completely draining your resources in the process?

    The answer: automation.

    Why is Security Vital to DevSecOps?

    To take full advantage of the agility and responsiveness of DevOps, you must bring forward an IT security team through the entire life cycle of your apps.

    In the past, when software could take months or years to complete, it was perfectly acceptable to bring in the security team in the final stage of development. But in the days of DevOps, a security team must get consulted from day one due to rapid and frequent development cycles.

    An effective DevSecOps system can be completed in days, so the outdated approach to handling security during the development phases also must change.

    How Did Security Radically Change DevOps?

    It is important to remind developers that security is a shared responsibility that must be integrated from end to end to guarantee a smooth and functional application. The mindset is so important that many have changed from using the term DevOps to DevSecOps to stress the importance of the need to build a very sound security foundation.

    If you are already making the transition to the cloud with AWS, chances are you have already implemented DevOps strategies into your interface so you can test new virtual machines (VMs) and deploy applications quickly without waiting for infrastructure to get manually configured.

    For those who prefer the old-school method of developing applications, neglecting security until the end leaves their applications exposed. One of the most common security issues with most SMEs is misuse of security during beta tests, which is basically akin to leaving your front door wide open when you go to sleep at night. It’s just a terrible idea.

    Making the transition from DevOps is not a luxury but a necessity for developers who want a secure environment, even during the dev/test period.

    Designing Compliance Processes for IT

    Even if you add “security” to the term DevOps, it means little without properly adding the processes you use into the building of the applications.

    Security must be built into the processes by design, or you are not correctly taking advantage of what DevSecOps means—and your developer resources will get neglected, too.

    Like the name implies, security must be in the center of development and operations. To maintain compliance, you must enforce a shared responsibility between AWS and the customer:

    • AWS is responsible for security of the cloud, including the hypervisor and hardware.
    • Customers are responsible for security in the cloud. They do this by securing your applications and network with services through a third-party vendor.

    The best examples of DevSecOps in the cloud take this philosophy to heart.

    Automation is Critical to Compliance Processes

    A “security first” mentality is good , but are you really taking action with your compliance processes to free up developer resources?

    The answer for many developers is, “Not quite.” Automation is essential to DevSecOps, yet so many systems lack the right tools. This is especially unfortunate for organizations that have the necessary skills and procedures in-house to implement built-in security processes directly into the application by design.

    For other organizations, automation is only achievable by leveraging their services from a security integrator, who can then provide services to help define processes and roles, unveil security tools and set up automation procedures.

    Steps to Establish Automation on DevSecOps

    Now that you know automation is crucial to the success of any system, here are a few basic steps you can take from day one to start building the security processes into your design:

    1. Consider a “shift-left” mentality when adding new processes, ones that incorporate design thinking from customers’ security needs and remain consistent. Steps such as threat-modeling storyboards build cyber resilience into the application before the first code is even written.
    2. Consider a cloud-based vulnerability scanning solution. It will help you define standards for the AMI as well as validate adherence to those standards.
    3. Implement an audit, logging and monitoring solution to track changes to the in-use AMIs. It helps combine account activity and AWS resources from the cloud with data related to security incidents. The in-use AMI changes can do everything from providing ongoing insights to allowing other security controls and having influence over network security.
    4. View the AWS Marketplace catalog. Along with what an internal staff or a systems integrator can help automate, there are a number of other terrific resources out there for automation. The software listings are all from independent software vendors that make it straightforward to locate, test, buy and deploy software that runs effectively on your AWS environment. Like other AWS services, the providers are billed based on consumption, so you pay only for what you need.

    By asking yourself the important question, “What am I trying to accomplish with my security controls?” you can get a variety of answers regarding what measures you need to take for compliance processes.

    Final Thoughts

    Speed, speed, speed. Developers today simply have no time to waste when it is time to launch new applications and get them out the door.

    You have little time to burn on extra features, but you also can’t afford leaving your systems exposed and vulnerable to attacks. That’s why DevSecOps uses superior security processes to free up developer resources by utilizing as much automation as possible.

    — Sam Bocetta