devopsy.kinsta.cloud

Tag: secure code

  • Threat Modeling as a DevSecOps Practice

    Threat Modeling as a DevSecOps Practice

    Software engineers are always under pressure to build more software, faster.  At the same time, there is increasing regulatory and market pressure for secure software that meets users’ and regulators’ requirements for data privacy.  This dynamic often puts software engineers at odds with application security or product security teams.

    In fact, 81% of developer teams at large enterprises have launched applications that feature insecure code, according to one researcher, with half doing this on a regular basis. The firm argued that developers and security architects need a better relationship, and I couldn’t agree more.

    These technical teams are working towards the same goal, so it’s in everyone’s interests—particularly senior leadership—to create a more cohesive working environment by breaking down barriers between teams. If the security of a system is designed and enforced by an external security team—disconnected from the rest of the engineering team—then this only reinforces security as a separate silo. But companies can ease tensions by embedding the responsibility for security in the engineering teams themselves: This is the thinking behind DevSecOps. Thinking about security starts when engineers think about solving the problem: At design time.

    While the shift left movement was born two decades ago with the goal of ensuring product testing happened early in the development stage, I believe we need to start left to make real change. In adopting this culture, security and privacy will be less of a bolt-on afterthought and a built-in fixture within the development process, ensuring that engineers and security teams alike are aligned and have visibility of each other’s objectives. 

    By reimagining the build, test, fix, build, test, fix cycle through building an architecturally secure design in real-time, technical teams can detect software vulnerabilities sooner rather than later, which means more efficient product deployment. This is where the process of threat modeling as a business tool can be of great benefit.

    Historically, threat modeling was a static, slow and manual process conducted on whiteboards, as part of a workshop led by a third-party security expert who lacked institutional knowledge of the inner workings of the company. However, this has evolved dramatically into an easily implemented, automated security practice that can be baked into the development and security cycle from the outset, empowering organizations to start left.

    Through automated threat modeling, the security workload burden is relieved for both security architects and engineers. Companies are, in turn, better positioned to keep pace with the cadence of ongoing software rollouts, as an automated platform suggests security improvements as an application evolves. The launch phase bottleneck that’s typically created during the testing stage is therefore removed, as security requirements are identified prior to development—which means that risk is managed before a line of code is even written. Based on this, it should quickly become apparent what a time- and cost-saving exercise threat modeling is.

    No developer or security specialist wants a flawed product to hit the market, so it makes good business sense to adopt a new approach that will lead to better outcomes. Enterprises that introduce threat modeling as part of their development and cybersecurity processes will be on course to embed a true DevSecOps system within the company, transforming the relationship between these two departments.

    In my experience, culture and growth are the key factors for enterprises that decide to adjust their cybersecurity diet to include automated threat modeling. Convincing the app dev teams to invest time into the process is, by far, the most significant cultural hurdle to overcome, because they need to witness the benefits—and up until this point they’re disconnected from the AppSec process.

    Once equipped with the tools and knowledge, delivering secure design will be second nature to developers and a new collaborative culture will be created. In essence, the more teams are given oversight of and accountability for software design flaws, the easier it is to recognize how vital these preliminary checks are.

    Likewise, there comes a stage of business growth when the ‘security first’ and ‘start left’ mindsets are essential to keep enterprise project management on track—and this ties into the culture. As the rate of scale within a company begins to increase and the pace of software deployment must quicken in line with customer demand and market competitiveness, discovering flaws at the end of the design process just isn’t an option. 

    With developers and security teams responsible for vast amounts of code, product resilience on delivery is crucial and ensuring a robust DevSecOps culture is the route to success.

  • Competing Priorities Prevent Devs From Creating Secure Code

    Competing Priorities Prevent Devs From Creating Secure Code

    The recently released Secure Code Warrior State of Developer-Driven Security Survey revealed that developers continue to wrestle with secure coding practices in a working environment that has long prioritized features and functionality and speed at the expense of security. 

    Of the more than 1,200 developers who took part in the survey, only 14% named security as their top priority. Security was seen as a bottleneck—an astonishing 67% of these developers said they routinely left known vulnerabilities and exploits in their code and 48% shipped products with known vulnerabilities.

    These statistics raise eyebrows, sure, but they are also unsurprising. In the survey, application security fell behind creating quality code, application performance and the ability to solve real-world problems on the list of developers’ priorities.

    In many cases, these results showed that security is either ignored in favor of meeting demanding timelines, developers would rather improve an application’s performance or they simply lack the required training to fix security problems. Regardless of the reason, it is a continuing problem.

    The Need to Balance Security in Development

    As the survey showed, developers often worked with secure code in silos. Security controls were limited to a single category instead of a holistic view of fundamentals. In many cases, developers relied on existing or pre-approved code rather than writing new code free from vulnerabilities. This assumed that the code inserted meets proper security needs, but that assumption often fell short.

    That said, developers who write code often find themselves inadvertently introducing vulnerabilities. This is not entirely the fault of those developers, but some of the blame lies with the cultural risk acceptance of the organization.

    The software organizations themselves must put more onus on secure development. As we saw from the SolarWinds attack, deficiencies in code can lead to massive disruptions. While not all application vulnerabilities have the reach of SolarWinds, businesses often allow for too much risk to pass in their code; that gets passed on to customers and developers are made the scapegoats.

    Provide Developers With the Right Skills

    Security leaders must first ensure developers have the requisite skills to code securely and to make improvements. That includes not just writing the code but also how code is committed through the entire development process. Developers often need hands-on training in proper coding patterns created in the languages and frameworks they commonly use.

    Organizations can no longer overlook security and ship potentially exploitable software. Security must be added earlier in the development process and be seen as imperative to success. The survey showed that many developers believe secure coding is out of their realm of expertise. A staggering 86% said they found it challenging to practice secure coding, while 92% of developer managers said their teams needed more training in security frameworks.

    This highlighted that developers do not get the right kind of training—nor are they get enough exposure to security best practices. It also underscores that designing for security is not seen as an essential skill for developers to have.

    Reasons for Optimism

    While our survey highlighted a disturbing trend, it also offered reasons for hope. The survey showed that attitudes have changed, and 66% of developers expected security to become a more significant priority over the next 12 to 18 months. Hiring managers echoed this sentiment—82% expressed an interest in hiring developers who are knowledgeable in security over those who are not.

    Businesses today have put themselves and their customers in a risky situation; organizational leaders must be agents of change to mitigate this risk. They need to apply a security-first mindset and empower their developers to better integrate security into the development process. Timelines must be revised to allow this to happen. If it continues, the current state of application security will only lead to more (and more severe) breaches. Now is the time to ensure DevOps teams and developers have better access to security training and more time to put those practices into action to ensure long term success. 

  • Secure Software Summit: Securing Software With Zero-Trust

    Secure Software Summit: Securing Software With Zero-Trust

    With the increase of supply chain attacks on everything from logging software like Log4j to takeovers of important JavaScript packages to compromises of network utility tools like SolarWinds, more and more organizations are recognizing the need to adopt a zero-trust mindset. Zero-trust can improve security, reduce risks and give organizations greater confidence in the integrity of their IT infrastructure and applications. To correctly set up a zero-trust architecture, you need to understand what it actually takes to make systems zero-trust.

    Zero-Trust Definition and Guiding Principles

    Due to the rise of interest in zero-trust, many misconceptions have built up that bear correcting. 

    • Zero-trust is not a product or tool. In fact, there is no single tool you can apply to an environment to configure a full-stack zero-trust implementation. Rather, zero-trust is more about creating and refining an architecture and applying a consistent mindset. 
    • Zero-trust is a never-ending journey. It is not a destination. You are never done; never finished setting up zero-trust, because software applications and IT environments continuously evolve. As your environment evolves, part of applying zero-trust is going back and reassessing everything you are doing on a regular basis to ensure it complies with the principles of zero-trust and covers all your software and technology assets. 
    • Zero-trust does not mean your environment cannot be hacked or breached. On the contrary, under zero-trust you constantly assume your environment has been breached. Zero-trust emphasizes building defensive layers that reduce the potential impact of any hack or breach and protects your assets and data.

    So, what is zero-trust? Zero-trust is a framework and approach to security that assumes an organization’s IT assets — software, networks, data — are constantly at risk and must be secured through continuous verification of the identity, and the application of least privilege principles against any identity — human or machine — operating inside the IT environment. The core of zero-trust is the lack of inherent trust for any identity as a managing approach to building more resilient applications and segmented risk.

    Zero-trust has several key guiding principles.

    1. Verify all identities, all the time, using a strong form of authentication — not just username and password. Specifically, use strong forms of authentication, such as multifactor authentication. This principle applies not only to human users but also to all devices, bots, services, APIs and partner systems accessing your environments. They must be verified every time they seek access and continuously while they are active inside your environment. 
    2. Always assume your environment has been breached. From this starting point, design your systems to reduce the blast radius and protect your assets as if an attacker is continuously present and moving within your environment to perform malicious acts — data exfiltration, system takeover, or other forms of abuse. 
    3. Always enforce least privilege for everyone and everything operating in your environment. Least privilege means limiting access only to systems, applications, data and services required for each task or interaction. To properly apply least privilege requires an understanding of expected behavior for applications and services, what they should and should not be doing, and also creating a sense of context. Applying least privilege with context is also dependent on assessing the security posture of any device, service, application, API or identity seeking access. Your zero-trust policy enforcement engines should always interrogate inbound and ongoing connections to understand where an identity is coming from, what it is trying to connect to and the current security posture of that identity. The answers to these questions should inform and shape least privilege permissions and provide additional insight into the risk of providing access.
    4. Segment your environment to limit horizontal traversals or pass-through attacks. This is closely related to least privilege. The bottom line: Do not award any identities carte blanche access to your network, applications data or infrastructure. Only allow identities access to the portions they truly need to perform their task, and only while they are performing that task. 

    Using Zero-Trust to Secure Software and Software Supply Chain

    The conceptual language of zero-trust makes it sounds like an identity architecture and network security approach, floating above developers. For building and deploying secure applications, developers and DevOps teams must also adopt a zero-trust mindset. In fact, there are clear synergies between zero-trust and application security — and particularly with regard to open source software (OSS). OSS developers may not spend sufficient time and energy on securing their code because it is not what they like about writing software. For this reason, if you are including OSS code (and nested OSS libraries) in your applications and environments, then you have even more reason to apply zero-trust frameworks. 

    A useful way to think about this is to consider zero-trust as applicable from the inside out, from the outside in and to everything in between linking internal and external, applications and APIs, code and integration/deployment pipelines and partner environments. Properly executed, zero-trust allows your developers to go faster but also be safer. Additionally, it is useful to view zero-trust through the confidentiality, integrity, availability (CIA) lens. You should design your zero-trust architecture to deliver these elements in a priority hierarchy that maps to your business needs. There are a few different ways to implement zero-trust principles in the software supply chain. 

    Assume Your Code has Been Breached and is Insecure

    Conduct a software asset inventory, looking at and categorizing all code running in your environment. This makes it easier for you to identify unauthorized changes and build more resilient applications. Set up mechanisms to detect unauthorized changes or anomalous software behaviors. You may want to apply these guidelines to close partners and their software and supply chain, as well. Remember that attacks may be from you, through you, or at you. 

    Manage Identities Carefully

    Analyze and categorize user entitlements to set a baseline for least privilege. Conduct an inventory of all identities active in your environment to identify known identities (and quickly recognize unknown identities). Set up mechanisms to analyze the behavior of identities to spot anomalies and create a baseline for context and behavioral privilege and access policy decisions. Include partner identities in this inventory: Your greatest risk may come from unsecured partners that attackers use to gain access to your environment. The inventory should also include service and admin accounts. The inclination is to set their privileges and forget about them, often awarding broad access so as not to slow them down and also potentially providing an unmonitored backdoor to attackers. 

    Take Inventory and Lock Down Integrations

    Inventory your external and internal supply chain. This includes all dependencies in the code, services called, APIs exposed or accessed and tooling for developing, hosting, integrating and building applications. For example, you may want to analyze your CI/CD pipeline and deployment environments through the lens of segmentation and least privilege to limit access depending on the pipeline stage. Put in place measures to segment the software environment and prevent lateral movement, like application sandboxing (but make sure to also tightly secure your sandboxes). 

    Code Assessment

    Developers need to apply threat models to their code and adopt the mindset of considering what an attacker might access and what they might do should they compromise an application or the surrounding supply chain. Obviously, for all code — and especially OSS code – developers will need to continuously look for vulnerabilities and scan code using tools like static code analysis and dynamic application security testing. Zero-trust means continuous verification of your own code, not just the entities using the code.

    Zero-Trust Takeaways

    As we continue towards a future of more complex and integrated application environments and more usage of OSS code for core application functionality, the zero-trust future becomes zero-trust forever. It will simply become a way of life in application development. That said, we should keep in mind four key guiding principles. 

    Know Your Current State—Be aware of where your environment stands and your security posture, and direct and indirect impacts of security vulnerabilities.

    Assume Breach—Be able to identify anomalous behavior and continuously consider what could be done by an attacker if your app was used maliciously?

    Assess—Continuously assess the status and changes in the environment. Ask questions like: Who has what, when and where? Where do your integrated partners and vendors stand in terms of security?

    Continuous Improvement—Periodically assess and compare your zero-trust efforts against desired security posture and make improvements that align with objectives around confidentiality, integrity, and availability. Constantly guard against risk. 

    These four principles map to five key takeaways that any developer, application security team, DevSecOps team or platform team can apply today and forever.

    • Review your environment with a zero-trust lens 
    • Recertify all identities continuously
    • Establish baseline app and identity behavior
    • Focus on detection and prevention of attacks
    • Design applications for resilience

    Following these guiding principles and basic framings will ensure your zero-trust journey creates strong defenses that help protect your development supply chain from the outside in, inside out, and with integrated partners.

    The Secure Software Summit brought together the world’s leading innovators, practitioners and academics of secure software development to share and teach the latest methods and breakthroughs on secure coding and deployment practices. If you are about developing, releasing and securing software, delivering new features fast and building things right from the start, click on the link below to get access to all of the sessions from this summit.

    https://go.shiftleft.io/secure-software-summit-2022-replay

  • Secure Software Summit Series: Focus on Preventative Readiness

    Secure Software Summit Series: Focus on Preventative Readiness

    The connected world economy and the COVID-19 pandemic forced companies to accelerate digital transformation. Sophisticated cybercriminals have seized this forced acceleration to lay the groundwork for cyberwarfare. In reaction to recent attacks ranging from the SolarWinds breach to the recent Log4Shell exploits, many companies have quickly isolated and patched their systems. However, these reactive fixes do not work all the time; nor does the watch-and-wait approach. We must focus on re-engineering our organizational operations and culture to build and maintain preventative readiness. Companies and infrastructures need to be more resilient and secure from the start by building secure coding practices into the development process.

    Secure Software Summit

    At the beginning of 2022, ShiftLeft hosted the Secure Software Summit to provide industry experts and practitioners in the software development world a platform to discuss the latest methods and breakthroughs in secure coding and development practices—securing code earlier and better has become a discipline unto itself!

    Some of the main takeaways from the event were:

    SBOMs are in Your Future

    In the very near future, organizations will need to better account for all the software and components of their applications, most likely via a software bill of materials (SBOM). The U.S. government has mandated barebones SBOMs, and we will soon see private industry start to mandate them, too, as part of procurement processes and auditing. This will enforce greater transparency and automate discovery of all dependencies and components in a way that, until now, was not common. Software composition analysis (SCA) will make this process easier and will become a standard part of the build process and the application development life cycle.

    Securing Open Source is Critical

    With Log4Shell and other open source software (OSS) supply chain attacks, application security teams must learn how to more intelligently update and secure the most critical OSS components and infrastructure. The average AppSec team needs to sift through massive piles of vulnerabilities and suggested security fixes — far more than they can possibly fix. We have seen record numbers of new vulnerability disclosures in each of the past four years. Proper prioritization based on whether a vulnerability can significantly impact an organization’s own applications and infrastructure is now essential amidst the blizzard of OSS dependencies that make up the modern application.

    Digital Threats Impact the Real World

    For many organizations in non-tech verticals such as health care that consume a lot of software, application security is at a crisis point—software vulnerabilities can literally put lives and our economy at risk. Researchers have correlated increases in mortality with hospitals running at higher levels of stress and capacity. When ransomware or other attacks impact health care institutions, the effect is the same as a massive pandemic flooding the ER: Doctors can’t use systems or equipment, care is rationed, patients are turned away and everything becomes more time-consuming. The net result is more deaths. Securing these systems against attacks becomes a matter of life or death—literally.

    Culture Change Must Come First

    Organizations will deploy new security architectures such as zero-trust, but these attempts will only be successful if AppSec and development teams change the culture around security. Organizations must recognize that the new normal is a state of constant renewal of trust. This will be challenging; constant renewal of trust requires entirely new infrastructure and a new mindset that can be hard on humans. It means implementing multifactor authentication in many more places and removing conveniences like administrative accounts that have blanket access to systems; it requires implementing least privilege practices. Software development will need to bake this constant renewal of trust into workflows and tooling to make it the new normal.

    Shift From Reactive to Proactive

    AppSec and development teams must shift from reactive approaches that tend to mobilize most resources during a breach or an incident and emphasize more proactive approaches such as better software security analysis and security chaos engineering. Knowing the unknown unknowns before they become a problem is key here. Netflix, which pioneered chaos engineering, recognized that stressing systems frequently and constantly to see how they behave under adverse conditions often yielded surprising insights that could improve security (and resilience, more broadly). As mentioned above, creating better ways to prioritize vulnerabilities and focus on the ones that are actually attackable shifts the task from a hopeless burndown to a targeted and proactive tactical exercise that is manageable. 

    Stay tuned for more articles to follow written by the following keynote speakers from the event:

    • Aaron Rinehart, Verica – Security Chaos Engineering
    • Dan Lorenc, Chainguard – The State of OSS Supply Chain Security
    • Steve Springett, OWASP – Behold the SBOM
    • Shinesa Cambric, Microsoft – Importance of Securing Software with a Zero Trust Mindset
    • Malcolm Harkins (Epiphany Systems), Rob Lundy (ShiftLeft) and Bryan Smith (RiskLens) – Reachability and Attackability
    • Abhishek Arya, Google – Measuring and Mitigating Risks in Open Source Software
  • Secure Software Summit: Exploring Secure Coding Best Practices

    Secure Software Summit: Exploring Secure Coding Best Practices

    In an era where software is dominating the world, the security and quality of code must remain a high priority. Delivering secure and reliable software at a rapid pace is crucial for most organizations today, but it’s not an easy task. What security best practices do organizations put in place to successfully produce secure software? How should DevOps teams incorporate updated security practices and tools throughout the software development lifecycle? At Secure Software Summit, taking place Jan. 27 at 9 a.m. PT, the world’s leading cybersecurity experts will come together to share and teach the latest methods and breakthroughs on secure coding and deployment practices.

    The virtual event features thought-provoking discussions, networking opportunities and educational sessions focused on:

    • Open source supply chain security
    • DevSecOps
    • Shifting security left
    • Security Chaos Engineering (SCE)
    • Security and compliance
    • Security metrics
    • Zero trust

    Secure Software features an outstanding lineup of innovators, practitioners and academics of secure software development, including:

    • Aaron Rinehart, co-founder and CTO at Verica
    • Dan Lorenc, founder and CEO at Chainguard, Inc.
    • Shinesa Cambric, principal program manager, Identity Signals and Protection Team at Microsoft
    • Vickie Li, developer evangelist at ShiftLeft
    • Fabian Yamaguchi, chief scientist at ShiftLeft
    • Jonathan Schneider, co-founder and CEO at Moderne, Inc.
    • Abhishek Arya, principal engineer and manager, Google Open Source Security Team at Google
    • Steve Springett, senior manager of product security at ServiceNow and chair of the OWASP CycloneDX Core Working Group
    • Jasmine Jackson, senior application security engineer at Disney
    • Suchakra Sharma, staff scientist at ShiftLeft
    • Harini Rangarajan, engineering manager, product security at Twilio
    • Mark Wireman, senior manager at Accenture
    • Shannon Lietz, vice president of Vulnerability Labs at Adobe
    • Vandana Verma, security relations leader at Snyk
    • Yash, head of security at Sendbird
    • Chetan Conikee, CTO at ShiftLeft
    • James Chiappetta, SVP of cybersecurity at Blackstone

    Attendees will have access to valuable resources available for download and will also receive a link to access the virtual environment on-demand. To see the full agenda and to register, please visit the Secure Software Summit website.

  • Best of 2019: Critical Skills Developers Need to Avoid Getting Left Behind

    Best of 2019: Critical Skills Developers Need to Avoid Getting Left Behind

    As we close out 2019, we at devopsy.kinsta.cloud wanted to highlight the five most popular articles of the year. Following is the second in our weeklong series of the Best of 2019.

    Burnout is a recurring theme at DevOpsDays events around the world. The modern developer faces constantly and rapidly-evolving challenges: the agile movement reducing the development lifespan, the DevOps movement shifting production operational responsibilities into development processes and the complexity of cloud offering new architectures from SaaS through to FaaS, as well as microservices.

    As these shifts occur, often ignored are the operational skills needed to support an application running in production. Developers expect to support production and be on call 24/7, but are IT leaders giving them the necessary tools and training? More and more, we need developers to be prepared and able to seamlessly oscillate between focused specialist and broad generalist. This article highlights a few key areas where software engineers need to bolster their skill sets to remain agile and effective in building applications.

    DevOps and SRE Assume Broader Skills

    Non-developers may interpret agile computing as developers creating a world where they get to code rather than document, follow process or deliver to plan. In reality, agile took the lengthy cycle of waterfall releases and replaced it with the frenetic continuous delivery of valuable software. DevOps was born from the need to deliver application updates rapidly and regularly.

    The monitor phase of the DevOps infinite loop originally focused on ensuring application problem detection and diagnosis was possible. Moving from detection to prevention, DevOps practitioners had to shift their testing and quality processes. Developers were asked to code the application, while also creating the testing systems to validate their code and building the production executables. Progress here led to additional responsibilities. As development moved to agile and DevOps, infrastructure transformed into software defined infrastructure (SDI).

    The separation of the operating system from the server hardware through virtual machines started the journey to SDI. Application containers removed the OS requirement and added cross-server mobility. Kubernetes and Docker Swarm allowed developers to encode application requirements in the recursively titled YAML. After containers, microservices is a further refinement that isolates an action into a separate piece of code—which is well suited for workload-based pricing of cloud environments. SDI’s capabilities bring us to where infrastructure definitions require a software development lifecycle (SDLC) of their own.

    The outcome of all this is a massive increase in complexity that developers must consider as they code components of an application. It requires additional considerations of the infrastructure and business environment the application will run in. Developers can define the best YAML definition of needs for their new application, but does not mean the production infrastructure will be able to provide a matching environment.

    Skills Developers Must Enhance

    Here are some key areas where developers would benefit from honing their skills in order to stay relevant amid growing complexities mentioned above.

    Networking

    The single purpose of computer networking is to move data from the memory of one computer into the memory of a different computer. With TCP/IP protocols as the default network stack, the flexibility needed to survive a nuclear attack comes with a lot of variability in configuration. At the basic level, network components must be configured to identify how many bits of an address to use when searching for another network entity via Classless Inter Domain Routing (CIDR).

    Software engineers need networking skills to understand how their software definitions may conflict with the eventual production network infrastructure. For instance, network definitions in the YAML descriptors for Kubernetes/Docker are generally set with a /nn configuration (e.g. /16). Conflicts arise when you overlap the pod addresses with physical server addresses or have a mismatch between development pods and production pods. If your pods-per-node count differs between pre-prod and prod environments, it is possible the CIDR settings will differ as well—as a colleague regrettably learned when using /8 rather than /16, leading to the largest production outage in their career.

    In addition to these basics of network addressing, there are concepts such as micro-segmentation needing definitions of performance and connection requirements that span across containers, virtual machines and bare metal servers.

    Security and Segmentation

    Historically, applications have relied on production infrastructures with their firewalls and DMZs for protection from the outside world. That castle moat approach is insufficient for today’s threat landscape where applications live everywhere. Not only do enterprises need to protect against outside connections and attacks, they also need to prevent accidental connections from production applications to development, QA and testing environments. Crossing the streams can cause exposure of production data in test environments and, even worse, corruption of production data.

    Ensuring that application components only communicate to specific services in specific environments is addressed with micro-segmentation and its ability to manage and monitor secure code-to-code communication. Control with this detail comes with its own challenges as incorrect or insufficient definitions could leave a production application unable to communicate with needed API’s or microservices. Making diagnosis in micro-segmented environments harder is the possibility that traffic for other transactions or applications may be successfully crossing the same environment. This is when you may hear the classic “it is working fine in test” response.

    Micro-segmentation offers significant security benefits yet requires developers to clearly identify the required connections and components of any communication. The best time to note this is while coding, making this an important skill for the modern developer.

    Dev and Ops Synchronicity

    The synchronous arrival of DevOps and SDI provides a mutual opportunity for developer and operations teams. While developers need to learn production on-call skills and operations teams need to learn SDLC skills, both teams also need to remain current in security concepts. Some organizations tackle DevOps by creating merged teams, though members may continue to stay in their lane. Whether merging teams, or maintaining separation, it is beneficial to hold brown bag sessions to share information and help educate each other. Ask your operations peers to talk about their three most common production issues and the three most popular tools they use.

    An important aspect of the application on-call generalist is having the right tool supporting them to effectively diagnose production outages and slowdowns. Whether developed as an in-house solution (with incumbent technical debt) or selected as a product, you will need something that can see from end-to-end and allow the code-centric software engineer to drill into databases, storage, networks and code components from an application point of view without having to learn siloed management and monitoring tools for each aspect of infrastructure.

    While individuals come into a DevOps transformation with I-shaped specialists, they must leave as T-shaped engineers, thus enhancing their value to current employers and helping their career.

    — Marco Coulter

  • Implementing DevSecOps Goes Beyond Technology

    Implementing DevSecOps Goes Beyond Technology

    While technology is crucial for implementing DevSecOps, it is the people, processes and culture that drive it forward. As recently as last year, a survey found 58% of technology leaders cited existing culture and lack of skills as hurdles to being able to embed security testing and evaluation within software development processes. That report found that only about one in four companies strongly agreed their organization’s culture and practices supported collaboration across development, operations and security.

    A separate recent survey on DevSecOps skills, conducted in partnership with devopsy.kinsta.cloud, found 70% of respondents said the security education they received is not adequate for what their current positions require.

    Plenty of similar statistics can be found, and they point to a recurring theme–education, training and support for developers and security teams are as critical as modern application security solutions in implementing DevSecOps.

    Automation Can Help Overcome Challenges

    Most developers want to create high quality, secure code. Often, the problem is developers have never had formal training in what secure coding is, in either traditional education or while on the job. The good news is more organizations are starting to provide that training for development teams. As development and release cycles speed up, developers need to find ways to incorporate security testing in less intrusive ways.

    In addition, development teams are gaining some control over budgets directed toward application security tools. Legacy tools for testing code and assessing application security risk simply weren’t built for the speed DevOps testing requires. Whenever evaluating new security analysis tools for a development team, automation should be top of mind. Static analysis tests the application code for a broad range of security flaws, and it can be fully automated into both the IDE and continuous integration (CI) processes. In the IDE, it provides early security guidance and education to software engineers while they are coding by highlighting potential vulnerabilities and suggesting best practices.

    Companies can also reduce friction by ensuring developers don’t have to go out of their way to run the security tool. Development teams should be able to view and triage the results and take advantage of plugins and/or APIs to integrate security tools seamlessly into toolchains they are already using. This means there will likely be no one-size-fits-all approach that can be dropped into any dev team; rather, take the time to understand how that team works currently, and work with them to introduce the security tools in the least disruptive way.

    Shifting Mentalities

    One of the biggest challenges is asking developers to do something they weren’t doing before. With DevSecOps, it may seem like dev teams are being asked to take on more work, but in reality, the organization is replacing unplanned work with planned work. Rather than address defects late in the release cycle, development teams are scanning for and addressing flaws early on. Such a cultural shift can be plodding, but developers and development managers should realize embedding security this way will be more efficient and more secure while also reducing their unplanned work.

    Giving development teams more autonomy over security tasks can also be daunting for security practitioners, but in order to facilitate shorter development iterations, security has to relinquish some control and also reconsider how they think about risk tolerance within the context of the business. Historically, the relationship between developers and security practitioners has been adversarial, but DevOps and DevSecOps methodologies have made it more cooperative. Still, many security teams are uncomfortable with the thought of giving up control.

    Adapting to Avoid Adding New Technical Debt

    Even with the understanding that producing more secure code benefits both development and security, reducing technical debt is gradual and starts with integrating security directly into the development process. It may seem convenient to lump security findings in with technical debt with the intention of getting to it someday, but it’s not practical to let security debt pile up.

    Organizations are decentralizing security work, particularly via security champions: One or two people on each development team who serve as the eyes and ears of product security, taking ownership of some of the day-to-day tasks that would have previously been bottlenecked on the security team. A security champion could help with security code reviews or coach others on their team on how to fix security issues. Sharing responsibility for security in this way can further bridge the gap between security and development teams, reducing the workload of the security team while allowing development teams to be more self-sufficient.

    For developers, context switching has a productivity cost. If they find out about a security defect while they are actively working on that particular feature or section of code, it’s only minimally disruptive and can be fixed quickly. By contrast, if they discover the same security defect two weeks later, after they’ve moved on to a completely different feature, they’ll incur the cost of context switching back to the earlier feature before they can fix the flaw correctly. Over the long run, finding and fixing flaws early in the SDLC should not meaningfully delay time to market.

    Here are some best practices in implementing DevSecOps in your organization.

    1. Embed Security Processes Early in the Development Cycle

    Ensure scans are baked in at every stage of the software development process and work with your development teams to integrate security within existing workflows and tools. By the time software is pushed to production, code should have been scanned multiple times and all vulnerabilities should be fixed. Research has shown the frequency of security scans during the development process correlates to fix velocity. Specifically, businesses that do daily scans fix vulnerabilities 11.5 times faster than the typical organization.

    2. Give Security Responsibility Directly to Development Teams

    Developers need to take ownership of the security of their applications. This is the only way to integrate security seamlessly into their existing workflows. The perception of someone coming in and forcing tweaks to their code can be discouraging, but that isn’t to say security teams should be hands off. They need to take an advisory role, working with developers to ensure secure code. Training is key here. It’s likely developers will not be acquainted with the latest security strategies. Security experts need to educate developers on known vulnerabilities, threats and tools.

    3. Identify a Security Champion on Every Development Team

    It’s equally important to find someone on the development team who can go beyond automated testing tools to serve as the eyes and ears of the security team. Rather than assign the role to a member who already has additional responsibilities, choose someone who shows an interest in security. Because engineers may switch teams often, it’s best to have at least two security champions on each dev team. If one moves on, the institutional knowledge remains on the team and a new security champion can be trained up.

    4. Automate Security Scans

    Security cannot be an inhibitor to development. If it is, developers will fail to implement the proper security policies. With automated tools in place, development teams can efficiently test code throughout the software development lifecycle (SDLC), ensuring more secure applications while delivering software on time.

    5. Take a Data-Driven Approach to Tracking Progress

    Showing progress is crucial, both for developers who want to see the impact security is having on their software and for the management team who needs clear insight into application security’s return on investment. Analytics with compelling visualizations supports this value by providing quick and intuitive data so organizations can assess their current state and take action to improve their risk posture. Sophisticated analytics allows organizations to target critical applications and fix critical findings by defining a custom security policy based on their specific risk tolerance.

    — Chris Eng

  • Debunking Myths Around RASP

    Debunking Myths Around RASP

    Runtime application self-protection (RASP) has taken a fair bit of scrutiny over the last few years. Like many security technologies that pioneer new ways of tackling old problems, people inherently don’t like change. Several companies entered the space early and early adopters helped mature various RASP solutions on the market and the technology has advanced rapidly.

    When applications began to be the favored target of bad guys, tons of companies started to reposition their perimeter security products closer to the application. Web application firewalls (WAFs) are similar to IPS for the network, so easy mind shift for most security practitioners. The problem is they require you to know your adversary. That’s like asking a security guard to keep out a single troublemaker, while letting in their associated gang of thugs.

    As we saw recently with WebLogic, exploiting applications is a shell game. When one vulnerability is exposed and patched, another one, which shares the same modus operandi, comes out. When reports came out comparing the most recent WebLogic vulnerability to vulnerabilities found last year in CVE-2018-2628, CVE-2018-2893 and CVE-2017-10271, Oracle posted a blog explaining last year’s vulnerabilities had been patched. The problem was the underlying code mechanism that led to the above-mentioned CVEs (insecure deserialization) had not been fixed.

    Deserialization is a perfect illustration of why RASP is the Chuck Norris of application security. Instead of applying a patch (which in the case of Oracle’s WebLogic, blacklisting the exploit method via a patch), RASP looks at the totality of the code before it executes and says, “If it looks like a duck and quacks like a duck, apply a roundhouse kick to the entire enumeration.”

    It’s important for enterprises to protect their customers from insecure deserialization with RASP products. Further, it’s critical to consider learning and debunking some of the common misconceptions in the overall perception of runtime security:

    Performance Impact

    Evaluate an agent-based solution, which often makes app owners concerned it’ll impact the performance of their applications. When evaluating RASP providers, especially agent-based solutions, ask for agent size, performance benchmarks and certainly conduct your own performance testing during evaluation.

    Writing Secure Code

    With the DevOps movement, companies have ramped investments in training and programs around secure development practices. And while security is shifting left with this movement, programming still has a little bit of art infused, especially when developing applications that have been around for a long time and have seen variations in development resources. As is the case with WebLogic, application developers should create apps with security in mind, but they don’t have a crystal ball and exploits evolve just as applications do.

    My Developers Will Become Lazy

    Somewhere in these early days of RASP, the notion came about that RASP means you no longer need to remediate vulnerabilities in your application source code. Notably, the root cause of all vulnerabilities should be fixed as soon as possible. However, RASP can also function as an insurance policy allowing DevOps teams to better plan fixes and prevent derailing other projects focused on the business.

    Why Do We Need RASP If We Have a WAF?

    The WAF has become ubiquitous in most organizations and it is certainly valuable for organizations looking to take a defense-in-depth strategy. WAFs have become a significant strain on resources as they produce unmanageable amounts of false-positives that require constant tuning. In a recent survey by Ponemon, it takes most organizations 45 hours a week to address alerts and 16 hours per week creating or updating rule sets.

    Hopefully, this article illustrates more color to today’s RASP. We’ve seen a lot of advancements in the early days of this technology and hopefully that will mean a lot less headlines.

    — John Adams

  • 4 Things Developers Should Know About Security in the Age of DevSecOps

    4 Things Developers Should Know About Security in the Age of DevSecOps

    If you’re a developer, most of your experience when it comes to security probably centers on designing and writing secure code. You know how to prevent buffer overflows, architect your microservices in a way that helps mitigate the impact of a breach and otherwise churn out secure application code.

    But the fact is that today, knowing how to keep the application itself secure is not enough—even if you are a developer. We’re living in the age of DevSecOps, and developers everywhere are being asked to play broader roles in security at all stages of the application delivery pipeline, from code implementation through to production release and management.

    With that reality in mind, here’s a look at four things developers should know about security today.

    What is DevSecOps, and What Does It Mean for Developers?

    Before diving into four critical things for developers to know in the age of DevSecOps, let’s take a look at what DevSecOps means.

    You’ve probably heard of DevOps, an approach to software delivery that emphasizes constant collaboration between developers and IT teams.

    DevSecOps extends that concept by adding security to the equation. For organizations that have embraced DevSecOps, the entire software delivery team becomes responsible for helping to secure the application. Security is no longer the exclusive domain of security engineers.

    In practice, DevSecOps includes work such as integrating vulnerability scanning into the build process using tools such as Packer and ensuring that images used for deployments meet GSO guidelines. Applying OWASP’s “Security by Design” principles is also a good best practice.

    What that means for developers (to put it simply) is that being a security-minded developer means more than just writing secure code. Developers must now understand security challenges and best practices at all stages of the software delivery pipeline, starting with the design and implementation of code—developers’ traditional domain—and continuing through with testing, staging, deployment and post-release management—all of which traditionally were not areas in which developers played much of a role.

    This isn’t to say that developers now have to bear primary responsibility for all of the things that happen after code is written. They don’t. Their main job is still to write code. But developers should have a solid understanding of the security implications of everything that happens once they hand off code to other members of the software delivery team, to ensure they are doing their best to write code that will stay secure as it travels down the pipeline.

    DevSecOps Security Lessons for Developers

    If you’re a developer, the DevSecOps trend means you should now have some expertise in the following:

    Microservices Security is Difficult (and Developers Can Make it a Little Easier)

    Microservices architectures, which have become very common because of the agility they provide to applications, create extra security challenges that were not present in monolithic architectures. The main reason why is that microservices add many more moving pieces to an application. As a result, there are more potential security vulnerabilities within the application, and detecting those vulnerabilities can be more difficult because there is more activity to monitor.

    Developers can help to address this challenge, and one way is to think about security monitoring complexity when they are deciding how many microservices to create. If developers can reduce the total number of microservices in an application without sacrificing agility, they can simplify security monitoring and enable a more secure application overall.

    Developers also can make sure the microservices they write log security-related information sufficiently and clearly. You don’t want to make it more difficult for your colleagues who are monitoring an application to keep track of security events because the application doesn’t log authentication information in sufficient detail, for example.

    You Can No Longer Count on Firewalls

    In the days when most software ran on-premises, firewalls were a handy way of isolating applications from most security threats.

    Today, organizations face a string of cloud security challenges that didn’t exist when firewalls were designed. Firewalls can still be helpful in some circumstances, but in many cases, you can no longer neatly segment applications or services off from the public internet, because you need the internet for services that are spread across a hybrid infrastructure to communicate with each other.

    For developers, the lesson here is that it’s especially critical to design and write code that can resist threats that originate from the internet. Even if you don’t expect a particular part of the application to be exposed to the public internet, assume it might be, either because deployment patterns change in the future or the component is exposed without anyone realizing it.

    To put this another way: Developers can’t and shouldn’t expect the IT team to be able to erect firewalls that will keep applications secure. More of the burden has shifted to developers to write applications that can resist network-based security threats because the IT team can no longer deploy firewalls like it used to.

    Shift Security Testing Left

    DevSecOps goes hand in hand with the mantra of shift-left testing. The latter term refers to the practice of performing tests earlier in the software delivery pipeline, rather than waiting until just before deployment to do the tests.

    Shift-left testing can apply to any type of software testing, including security tests. For developers, taking advantage of shift-left security testing is a useful way of identifying security flaws within newly written code early, when they can be fixed with less effort because they have not yet been integrated into the broader application code base.

    Security testing at later stages of the delivery pipeline is important, too, especially because you won’t be able to detect all security flaws until you can monitor all of your microservices as they interact with each other. But the time developers have to spend rewriting code to address security issues will be reduced greatly if their organization takes advantage of shift-left security testing.

    Don’t Be Afraid to Ask for Compliance Help

    A final point worth mentioning relates to compliance. Compliance is becoming ever-more challenging. And so is creating applications that meet the security requirements of compliance frameworks.

    In the past, developers were often left on their own to figure out how to address compliance needs. Given the spirit of collaboration that DevOps and DevSecOps champion, however, developers should no longer feel like they have to go at it alone when it comes to interpreting and addressing compliance requirements. And indeed, they shouldn’t. If you are a coding expert, you’re probably not an expert in figuring out what complex compliance frameworks require.

    The point here is that developers should not be afraid to ask for help—from legal experts, management or the IT team (which is more likely to have some experience with the compliance issues that arise once the software is in production) to make sure that the applications they design and write meet compliance requirements.

    Conclusion

    The developers’ main job is still writing code. But by having a greater awareness of the types of security risks that can arise within the code as it is pushed down the delivery chain, developers can do much to improve the security of the applications they write. They might even save themselves some time and headaches by reducing the number of complicated security issues they end up having to address by rewriting code.

    This sponsored article was written on behalf of Symantec.

    — Chris Tozzi