devopsy.kinsta.cloud

Tag: security champion

  • What Developers Need for Software Security Success

    What Developers Need for Software Security Success

    Given today’s evolving threat landscape, organizations and businesses in every sector now have a critical need to produce secure software. Criminal gangs, professional attackers and hostile nation-states are employing advanced tactics designed to exploit any vulnerabilities in programs, applications, networks and even raw code. Attackers are constantly finding new ways to bypass even the most advanced protections and defenses. For example, many have shifted their focus from delivering malware to instead compromising credentials, or launching targeted attacks against a supply chain. And while those high-level incursions are happening with much greater frequency, so too are the more basic attacks like ransomware and SQL injections that have been a scourge on cybersecurity defenses for many years. It’s becoming apparent that while cybersecurity platforms and defenses are critical components in defense against modern attacks, what is truly needed is secure code that can be deployed free from vulnerabilities. And that requires security-aware developers with verified security skills.

    Most developers say they are willing to champion security and commit to higher standards of code quality and secure output, but they can’t do it without a lot of support, as well as a reworking of the traditional metrics by which they are often judged by their employers and organizations.

    Why Most Developers Don’t Prioritize Security

    Coding best practices have continued to evolve over the years in response to business needs and market trends. In the past, most applications were created using the so-called waterfall development model where software engineers worked to get their code ready to meet an ongoing series of milestones or goals before moving on to the next phase of development. Waterfall tended to support the development of programs that, having met all of the previous milestones along the way, were free from bugs or operational flaws by the time they were ready for the production environment. But it was slow going, with sometimes 18 months or more between starting a project and getting to the finish line.

    The Agile method tended to replace Waterfall, putting a much greater emphasis on speed. And this was followed by DevOps, which is built for even more speed by combining development and operations together to ensure that programs are ready for production almost as soon as they clear the final development tweaks.

    Putting speed over security—and nearly everything else beyond functionality—was a necessity as the business environment evolved. In a cloud-based world where everyone is online all the time and mobile transactions by the millions can happen every few seconds, getting software deployed and into the continuous integration and continuous delivery (CI/CD) pipeline as quickly as possible is critical for business success.

    It’s not that organizations didn’t care about security. It’s just that in the competitive business environment that exists in most industries, speed was seen as more important. And developers who could match that speed thrived to the point where it became the primary means by which their job performance was judged.

    Now that advanced attacks are ramping up so dramatically, deploying vulnerable code is becoming a liability. The preference is once again shifting, with security increasingly becoming the primary focus of software development, with speed a close second. Bolting on security after the fact is not only dangerous, it also slows the process of deploying software. That has led to the rise of programs like DevSecOps that attempt to merge speed and security together to help generate secure code. But developers trained for pure speed can’t become security experts without a lot of help and support from their organizations.

    What Developers Need

    The good news is that most developers want to see a shift to secure coding and a reprioritizing of security as part of the development process. In a comprehensive survey conducted by Evans Data of over 1,200 professional developers actively working around the world earlier this year, the overwhelming majority said they were supportive of the concept of creating secure code. Most also expected it to become a priority in their organizations. However, only 8% of the respondents said that writing secure code was easy to accomplish. That leaves a lot of room for improvement within most organizations’ development teams between what is needed, and what is required in order to get there.

    Simply mandating secure code won’t get the job done. Development teams need training, support and a change in how software engineers are valued and judged within their organizations.

    The biggest thing that is needed is more and better training for them. And it should be customized so that less experienced developers can begin their training by learning how to recognize the kinds of common vulnerabilities that often creep into code, with lots of hands-on learning and examples. Meanwhile, more advanced developers who demonstrate their security skills can instead be tasked with things like advanced threat modeling concepts.

    Teamwork should also be emphasized so that the developer community can help one another grow their skills. Skilled and willing developers who know security should be appointed as security champions. Their responsibility as a champion will be to help fellow developers improve their skills. And while a security champion is almost always an informal title, they should be given the respect, rewards, and compensation that such an important position deserves.

    In addition to funding and supporting training programs and security champions, including giving developers enough time away from coding in order to properly participate in those programs, organizations also need to change the way that developers are evaluated. The primary metric for rewarding developers needs to shift away from raw speed. Instead, evaluations could reward those developers who can create secure code that is free from vulnerabilities or exploits. Yes, speed can be an evaluated factor as well, but first and foremost, code needs to be secure and free from vulnerabilities.

    Producing insecure or vulnerable code is no longer an acceptable risk for most businesses. And bolting on security after the fact is becoming increasingly ineffective. Thankfully, the best weapon to fight this disturbing trend is having the developer community produce secure code that attackers can’t exploit. Most developers are willing to step up to that challenge. They just need the proper training and support to help make it happen.

  • Are Developers Your First Line of Security Risk or Defense?

    Are Developers Your First Line of Security Risk or Defense?

    Every organization on the planet, whether public or commercial, is facing an ongoing challenge: to exist in an increasingly digital space. Past products must transform to meet the digital expectations of their customers, and new products must be built with “digital-first” frameworks in mind. After all, if they fail to meet these expectations, there’s almost certainly a competitor ready to swoop on the opportunity.

    So, what does that mean for all these businesses, old and new? It means they are employing teams of developers to create line after line of the code that forms their digital product or service.

    In this fast-moving, high-pressure environment, CIOs have become the new innovators, and are in positions of immense influence. However, they face a strong demand to meet rapid speed-to-market goals, enhance product quality with each update and increase flexibility. This has led to complex, often fragmented development teams whose primary focus is on rapid development of features and functions, without consideration of the vulnerabilities they could be creating in the code they are so quickly churning out.

    If our data is to remain safe, we must implement a new way of working. Just look at the catastrophic damage Equifax faced following its recent breach: a disaster that occurred as a direct result of insecure coding practices.

    CIOs and CISOs need to consider carefully whether their development teams are in fact the first line of data breach risk in the organization or the security champions, their company’s true “first line of defense” against cyberattacks. If they’re not the latter, they certainly could be.

    Secure Coding Checklist

    Where does your own dev team fit? I have created this Secure Coding Checklist to help CIOs and CISOs identify whether their development teams are truly equipped to be secure coding champions, helping to innovate with faster, better and safer code (or, indeed, whether you’re in need of a more robust security program):

    1. Is there acknowledgment at your executive C-level that traditional network security is no longer enough?

    These days, securing the network layer using traditional security measures is simply not good enough (and, let’s face it, is rarely successful anyway) even against semi-professional hackers. Among many consistent reports, Verizon’s “2017 Data Breach Investigations Report” cites that 35 percent of data breaches today are caused by web application vulnerabilities.

    Web application security is equally as important as network security; ignoring fundamental, protective AppSec measures could leave you well and truly open to a breach.

    2. Are you considering security from the start?

    The current approach to application security utilizes tools that focus on moving from right to left in the software development life cycle (SDLC). This, by design, supports a detection and reaction outcome. This means that security teams search for and detect vulnerabilities code that is already written, then react to fix them. According to the National Institute of Standards and Technology (NIST), it is 30 times more expensive to detect and fix vulnerabilities in committed code than it is to prevent them as they are written in the IDE. This doesn’t even take into consideration the production delays, double-handling and time spent in remedying any issues. Secure code champions start at the extreme left of the SDLC, with a focus on continually training their developers in secure coding, so they can be the first line of defense in their organization, preventing common vulnerabilities from occurring in the first place.

    3. Do you actually make the effort to build security skills, or are you just feeding knowledge?

    The vast majority of security training solutions (online and in-classroom) focus on building knowledge instead of building practical skills. For developers to thrive and engage in writing secure code, they need regular access to hands-on learning that actively encourages them to learn and build their skills in a real environment. They need to learn about recently identified vulnerabilities, in real code, and be able to work in their own languages/frameworks. This learning experience should help them understand how to locate, identify and fix known vulnerabilities in the code they are actively working on in the course of their jobs.

    4. Are you measuring your secure coding skills with real-time metrics?

    A vital step in ensuring a security-first mindset is being built within a development team is to collect and review evidence. Metrics seek to prove to the developer and their organization that their hard work is paying off, and secure coding skills are improving. You can’t improve what you cannot measure. There should be relevant assessments, and these should help identify the progress of your development teams in real-time as well as benchmarking their secure coding strengths and weaknesses for continuous improvement.

    5. How sure are you that any outsourced vendors are actively using secure coding techniques?

    Many organizations decide to contract out development work to other development houses. Whether they exist on- or offshore, their general secure coding abilities and practices are a relative mystery. In the best case, the only form of assurance an organization will receive relating to security is a statement in the contract requiring the deliverable to be “secure.” Few companies actually take the step to verify the skills of these development houses upfront, thus winding up with software that has been built without following sound secure coding practices. Worse yet, if the company is not aware of them, it risks going live with a vulnerable application.

    The most common scenario is that any vulnerabilities get picked up by dedicated security specialists (that come at a high cost) and you are faced with a delay of your go-live date, and possible contractual discussions on who needs to pay for fixing these security weaknesses. However, if you’re smart upfront and assess the application security skills of the developers who are going to build your next application, you save a lot of potential delay, frustration and cash.

    6. Are your developers aware of the most common security weaknesses?

    More than 85 percent of exploited web application vulnerabilities are attributed to just 10 known vulnerabilities—the OWASP Top 10. At a bare minimum, your application security training must cover these, in addition to many more vulnerability types. The training challenges your developers contend with must be actively revised and updated on a regular basis, with new challenges for either new coding frameworks or new vulnerability types.

    7. Do you have in-house security champions?

    Every developer-heavy organization should invest in a security champion—someone who is going to take responsibility for a security standard within the dev team. Their purpose is to be a support point of contact for anyone with questions around security, as well as become the chief advocate for following security best practice.

    8. Have you invested in tools for your developers to make secure coding easier?

    If your organization is one in which agile development is practiced, or indeed you are faced with frequent updates to company-built applications, automating parts of your security is one of the only ways to keep up with the frantic pace and volume of work.

    There are tools available at each stage of the SDLC that will serve as advisers, quality gatekeepers or detection tools. Ideally, you should have IDE plugins that focus on certain types of security bugs and act almost like a “spell-checker” while developers are writing their code. There are others that integrate with the build process, detecting certain types of weaknesses as the code is being submitted to a code repository.

    In addition, some tools run automated tests over the code, simulating attempted hacking once the software is in production. All have their own set of benefits and challenges, and none can provide a catchall, 100 percent guarantee that no security threats exist within the application. The No. 1 preventative measure you can employ is that the earlier you can capture the weakness, the faster and cheaper it is to remediate it with the least impact on your business.

    CISOs and CIOs are essentially forced to quickly and aggressively build their enterprise agile capabilities. As such, secure coding skills will be a weapon—not a hindrance to—innovation, and foregoing them could spell the absolute destruction of company reputation and data. Think twice before you skip this critical capability.

    So, how did your organization fare against this checklist?

    — Pieter Danhieux