At Secure Code Warrior, we are always looking to expand our training coverage. To empower embedded developers and security managers to build secure embedded systems, we are tapping into the world of embedded systems security. In this post, we will talk about the MISRA C 2012 standard, and why its compliance is necessary to build secure embedded systems.

While writing code in C, it’s very easy to implement things that seemingly look right, but are inherently wrong. Your code may compile just fine, and even run well for a certain period of time. But the same code could crash, or exhibit undefined behavior, if your input size and/or memory grows. For example, a particular input number causing an integer to overflow, or a particular sequence of characters causing an array to go out-of-bounds.

This is where the MISRA C coding standard can help. The rules, guidelines, and best practices laid out by the standard, enable developers to write safe and reliable C code for embedded development. 

MISRA C 2012, the latest version of the standard, adds new rules, enhances existing ones, and addresses some discrepancies. If you are still using an older version, now would be a great time to switch. 

What is the MISRA C coding standard?

The MISRA C standard includes code safety, portability, and reliability guidelines for the C programming language. The first set of guidelines was released in 1998, which were specific to the C language. 

However, since then, the MISRA Consortium also develops coding standards for C++. Every MISRA C document contains a set of rules, non-compliant examples, and detailed sections on the background information that contributed to the development of said rules.

C and C++ are the most widely used languages to develop embedded software. One of the main reasons is that they are fast, having only 1 or 2 levels of abstraction over machine language. But this also means that writing safe code, particularly in C, is difficult, and prone-to-error. For example, in most high-level languages like Java and C#, you don’t have to worry about trivial things like garbage collection or dynamic typing. 

However, in C, there’s no predefined way to collect garbage, i.e. if you allocate a piece of memory for a data structure, you have to manually free it yourself, once you are done using it. If you don’t, C, unlike other languages, will not free the memory for you, which will lead to a memory leak.

MISRA C 2004 (C2) vs. MISRA C 2012 (C3) – What changed?

MISRA C: 2012, also known as C3, was first released in April 2013. Drawing knowledge from the works of thousands of people and organizations, C3 adds new rules, enhances the explanation and backgrounds of some existing rules, and closes some loopholes.

C3 supports the C99 version of the language, while also maintaining rules for the older ISO C90. The main focus area in C3 was to reduce the usual costs of rule enforcement, while also making the use of the C language safer in critical systems. All this makes it prudent to switch to the new standard, if you haven’t already.

Overall, here’s a list of the most significant changes:

• Correct issues that were found in the 2004 version.
• Significantly increase the number of decidable rules. A rule is decidable, if an analysis tool can help you determine conformity to it.
• Rules are categorized as “required”, “advisory”, or “mandatory”. Mandatory rules must never be broken, under any circumstances. Required and advisory rules can be violated in special scenarios, provided the violation is justified.
• Added guidance regarding how to apply rules to auto-generated code. This is very important because the same guidelines of human-written code, don’t always apply to that generated by a tool.
• Remove the overly generalized rules that forbade reasonable user behavior. E.g. previously it was recommended to not use macros at all, since they can lead to various difficulties and confusion (can’t debug macros, macros don’t have namespaces etc.). This prevented the use of macros, even in situations where they could provide an elegant, safe, and convenient solution. In MISRA C: 2012, new rules regarding macros were introduced, allowing people to use them carefully, whenever applicable. See the following excerpt, taken from a MISRA C document, that recommends using a macro over a function.

MISRA C rules in action

Enough talk, now it’s time to get hands-on with some MISRA C rules, with examples of how they apply.

Use compatible types as pointer arguments to memcpy, memmove, and memcmp

The standard library functions memcpy, memmove, and memcmp perform byte-by-byte move or comparison of the specified number of bytes. The Rule 21.15 of MISRA C 2012 standard dictates that the two function parameters should be pointers to the same type. A function call with incompatible pointer types could indicate a mistake. 

Consider the following image, taken from the official MISRA compliance document. The rule is required, decidable, and applies to both C90 and C99.

An example follows the rule description.

As you can see, since the objects are of different types (uint8_t and uint16_t), this is a non-compliant solution.

String handling functions that don’t take length as input shall not result in out-of-bound access

String handling functions from <string.h> that don’t take the length as an input, shouldn’t result in out-of-bound access. The relevant functions are: strcat, strchr, strcmp, strcoll, strcpy, strcspn, strlen, strpbrk, strrchr, strspn, strrstr, and strtok. The rule is mandatory, meaning it can never be breached, under any circumstances. It applies to both C90 and C99, and is undecidable.

The corresponding example is:

As you can see, strcpy in function f1, will copy beyond the length of the string, which can only hold 5 characters. We also have a compliant and safe use of strcpy, where the string will only get copied, if the contents of “str” will fit.

Validate externally received data

Dir 4.14 recommends checking the validity of data received from “external” sources. External input can be:

• Read from a file.
• Read from an environment variable.
• Any user input.
• Anything received over a communication channel. E.g. over a TCP connection or HTTP API etc.

This directive falls in the required category, and is applicable to both C90 and C99. The rationale for this is that a program has no control over data received from external sources, which means that this data can be invalid or malicious. E.g. a program expects a user to input a number, but the user enters a string. Before processing the input, the program must verify that it’s indeed a number.

How to switch to MISRA C 2012

Switching to MISRA C 2012 will require an update in your coding guidelines document. If you don’t use one, and instead rely on a static analysis tool (which is the recommended choice), you may have to get a newer version of the tool. Here are three tools that check for MISRA C 2012 compliance:

1. Cppcheck is an open-source tool that can check for MISRA rules, and also detect various kinds of bugs.
2. PC-lint Plus is a paid tool that comes with a 30-day evaluation period. In addition to checking for MISRA C compliance, it can also help identify potential bugs and vulnerabilities.
3. CodeSonar is another tool that checks for both MISRA C and C++ compliance.

There are also a few compilers that can test for MISRA compliance. In case a rule violation is detected, warnings or exceptions are raised accordingly. E.g. Green Hills Software provides compilers with support for all MISRA standards, for both 32-bit and 64-bit architectures.

Using Secure Code Warrior to upskill developers in MISRA C

Secure Code Warrior's flagship product - learning platform - has numerous interactive challenges, courses, and assessments that can help train developers to write secure C/C++ code. The content on the platform is framework-specific and highly engaging. Our C/C++:Embed coding challenges took inspirations from both MISRA C, AUTOSAR C++ (MISRA C++), and IEC.

Developers can embark on personalized learning journeys, where they identify C/C++-specific vulnerabilities and more importantly learn to fix those bugs. In this process, developers can keep track of their progress to identify their weaknesses, and even enjoy a friendly coding competitions with their peers. Find out more about how we help automotive and transportation industries with our solutions.

Want to find out how interactive and embed-focus our challenges are? Try some C/C++:Embed challenges on the learning platform today!

Embedded systems help deliver a lot of modern technology. From the adaptive cruise control on your car, to the Wifi on your smart fridge. With cyberattacks on the rise, securing these systems has become critical.

Embedded devices are prime targets for hacking, as a successful attack can give intruders access to the data produced, received, and processed by them. This can often have serious ramifications for the larger system being powered by the embedded device. E.g. shutting down an embedded device within the F-15 fighter jet, which collects data from various cameras and sensors, can significantly hamper the jet’s defenses.

We have written this article to cover everything you need to start developing secure embedded systems. Here’s what’s included: 

• What is embedded security?
• Challenges faced while implementing embedded security.
• What makes an embedded system “secure”?
• Why end-to-end security is important in an embedded ecosystem.
• Some embedded security tools.
• What do typical embedded solutions lack?
• Future of embedded security.

What is embedded security?

Embedded security provides the tools, processes, and best practices to secure the software and hardware of embedded devices. 

Because the hardware modules of embedded systems are small, they have various memory and storage limitations. Incorporating security measures into them thus becomes a massive design challenge. However, challenging as it may be, it’s a need-of-the-hour.

A lot of the gadgets and machines powered by embedded devices are also connected to the internet. This means that hackers can gain unauthorized access to them, and run any malicious code. 

A hack in an embedded device can often spread to other connected components, and/or cripple the entire system. For example, let’s suppose an attacker is able to gain control of an embedded device that allows drivers to put their car on auto-pilot. The hacker can then steer the car off-road, or into traffic, potentially causing a lot of damage.

Critical embedded system security challenges

Embedded system security doesn’t get the attention it warrants. Here are a few reasons why:

1. Lack of developer awareness:

Developers are usually unaware of the best practices for developing secure embedded devices. This is partly because of point#2, and partly because embedded applications are far more complicated than traditional software applications. Understanding their security implications, and writing safe, performant code for all use-cases, that too in a constrained, microcomputer environment, can be challenging. 

2. Lack of standardization:

There is a lack of cybersecurity standards for embedded systems. Even though the auto industry is slowly trying to change that. In the last few years, researchers have released quite a few publications that address cybersecurity considerations for smart vehicles. A few notable ones are SAE J3061, “Cybersecurity Guidebook for Cyber-Physical Vehicle Systems:” and UNECE WP.29 Regulation on Cyber Security and Software Update Processes.

3. Use of third-party components

A lot of embedded devices required third-party hardware and software components to function. Often these components are used without being tested for any security flaws and vulnerabilities. 

4. Out-of-date software

An out-of-date firmware is typically ridden with bugs and potentially exploitable vulnerabilities. Even though it can be especially hard to periodically update firmware on a small, embedded device, it’s not something that can be ignored.

5. Direct internet connectivity

Many embedded systems and devices are directly connected to the internet. This means that they don’t have the protection of enterprise firewalls, which can detect and prevent network attacks. With resources at a premium, it becomes very hard to implement rigorous levels of security in such a constrained environment.

6. Attack at scale

Embedded devices are usually produced at scale. This means that a single vulnerability or flaw can affect millions of devices, sometimes worldwide. Containing the impacts of an embedded system attack can thus be a massive challenge.

What makes an embedded system secure?

In the following sections, we will look at some software and hardware characteristics of secure embedded systems.

Hardware security best practices

A secure embedded system has:

• A trusted execution environment

A trusted execution environment (TEE) allows for hardware-level isolation of security-critical operations. For example, user authentication may get executed in a segregated area, which enables better safeguarding of sensitive information.

• Appropriately partitioned hardware resources

Different hardware components like processor(s), cache, memory, and network interfaces etc. should be appropriately segregated, providing their functions as independently as possible. This helps in preventing an error in one component, propagating to other components.

• Executable space protection (ESP)

Executable space protection, or ESP, is the practice of marking certain memory regions as non-executable. If someone attempts to execute any code within these marked regions, an exception is thrown.

Software security best practices

The following best practices should be kept in mind when building embedded software:

• Use secure boot:

When an embedded device boots, the boot image gets verified using cryptographic algorithms. This ensures that the boot sequence is correct, and that the software (firmware and any other relevant data) has not been tampered with. 

• Use a microkernel OS

A microkernel OS is much smaller than a traditional OS, containing a subset of its features. The kernel space is tiny, and a lot of user services (like file system management etc.) are kept in a separate space, known as the userspace. Since there’s less code and operations being run in the kernel space, the attack surface is significantly reduced.

• Use properly packaged software applications

Any-and-all software applications should be self-contained, and properly packaged. E.g. if an application requires a third-party dependency, it should not be installed globally on the operating system. Rather, it should be part of the application package/container.

• Validate all inputs

Any-and-all data received from external and/or untrusted sources should be properly sanitized and validated, before being passed to critical software and/or hardware components. 

If an application fetches data from an external API integration, and toggles some setting based on it, the received data should be rigorously validated before the setting is changed.

• Protect data at rest:

All the sensitive software, data, configuration files, secure keys, and passwords etc. that are being stored on an embedded device, should be protected. This is usually done via encryption. The private keys used to encrypt the data must be stored in dedicated, purpose-built security hardware.

The security pyramid -- End to end security for embedded systems

Gone are the days when security used to be an afterthought. A non-functional requirement. Today, security needs to be intrinsic. Devices need to be secure by design. To that end, it’s essential to implement end-to-end security requirements in an embedded environment. This means: think about security while choosing your hardware, while defining your system architecture, while designing your system, and of course, while writing code.

Start at the hardware

No matter how robust your software security may be, if your hardware is lacking, you will be susceptible to attack. On-chip security techniques can allow secure boot, and efficient management of cryptographic functions and secrets. Some hardware components can also enable the operating system to offer various security features like system-call-anomaly detection, file system encryption, and access control policies.

A fault-tolerant system

There are numerous reasons to architect a fault-tolerant system, and avoiding differential fault analysis attacks is only one of them. In such an attack, a potential hacker can use fault injection techniques to try and produce errors in an embedded device. However, there are several possible ways to detect and protect against such faults:

• Replicate the most critical operations, so that different outputs can be compared, at any given time, to detect the injection of a fault.
• Fail by default: When handling multiple conditions (within an If condition or a switch block), always fail in the default case, i.e. when nothing else matches.
• Introduce random behavior: Adding small, random delays before crucial operations ensures that their timing is never predictable. This is key in intrusion detection, as it makes it very hard for hackers to determine patterns of operation, and perform timing attacks.
• Protective shields: Manufacturers should use shields to cover the most crucial components, protecting them from external manipulation.
• Detect abnormal fluctuations: Sense for abnormal fluctuations in voltage, current, or other values, and raise exceptions accordingly.

Secure your application… and operating system

Building your device's defense at the application level involves:

• Choosing tested, reputable third-party software and hardware components that can be regularly updated.
• Upskilling developers in the best practices concerning embedded system security.
• Use a microkernel operating system to ensure that a bare minimum number of operations get executed in the kernel space.
• Monitor and protect against software attacks including viruses, Trojan horses, and malware.
• Remove any-and-all unnecessary services. Your firmware should only have what you absolutely need. E.g. you may not need to transfer files, or capture packets, so you can disable file transfer protocols, and network packages like telnet.
• Use secure protocols like SFTP, IPsec, SSL, TLS, SSH, and DNSSEC.

Tools for embedded system security

Here’s a non-exhaustive list of tools that can help in securing embedded systems:

• Bus blaster: A high speed debugging platform that can interact with hardware debug ports.
• Salae: Decode various protocols like Serial, SPI, and I2C etc. You can use protocol analyzers built by the community, or build your own.
• Hydrabus: Open-source, multi-tool hardware that can be used in debugging, hacking, and/or penetration testing of embedded hardware.
• Exploit: An open-source Internet of things (IoT) security testing and exploitation framework.
• FACT (The Firmware Analysis and Comparison Tool): Framework used to automate firmware security analysis.
• Routersploit:  An open-source exploitation framework for embedded devices.
• Firmadyne: Open-source system for emulation and dynamic analysis of Linux-based embedded firmware.

Where are modern embedded security solutions lacking?

Even though there are various solutions available for debugging, exploiting, and pen-testing embedded solutions, they are not being readily used. A big focus remains on securing the device physically, but not enough efforts are made in protecting against software-related attacks. Even the simplest and easily avoidable application security risks and vulnerabilities are still common among modern embedded devices.  

A big reason for this is the developers’ lack of awareness of embedded security. According to a survey conducted by Tripwire, 68% of IT professionals believe that their workforce is not adequately aware of potential vulnerabilities.

Developers don’t know things like: which security protocols to choose, which frameworks to avoid, which hardware components to segregate, how to deal with sensitive data, and how to determine which encryption algorithm is the safest. This general lack of knowledge, and disregard for best practices, make applications running on embedded devices, susceptible to compromise.

Future of embedded security

A lot of work is being done in the embedded security market. Experts believe that the market’s compound annual growth rate (CAGR) can reach a figure of 5.5% during the 2021-2026 period. With more and more IoT devices being launched, we can expect new embedded security standards to get established.

The increasing adoption of wearable medical devices is also going to increase the demand for dependable embedded security solutions. For devices to contain and process sensitive medical data, they need to pass certain security checklists, and we hope that’s going to make vendors and engineers focus on security more.

In the future, we may also have solutions that allow for remote visibility, monitoring, and control of the main software and hardware components in embedded devices. This will truly be a game-changer in the world of embedded system security.

At the end of the day, digital signatures, encrypting data, adding firewalls, implementing access control, and randomizing operations can only take you so far. To build truly secure devices, developers need to be trained to write secure code. Identifying potential security risks, and mitigating them during the application design phase, goes a long way in making systems intrinsically secure. 

How Secure Code Warrior can help

Secure Code Warrior's flagship product - learning platform - has numerous interactive challenges, courses, and assessments that can help train developers to write secure C/C++ code. The content on the platform is framework-specific and highly engaging. Our C/C++:Embed coding challenges took inspirations from both MISRA C, AUTOSAR C++ (MISRA C++), and IEC.

Developers can embark on personalized learning journeys, where they identify C/C++-specific vulnerabilities and more importantly learn to fix those bugs. In this process, developers can keep track of their progress to identify their weaknesses, and even enjoy a friendly coding competitions with their peers. Find out more about how we help automotive and transportation industries with our solutions.

Want to find out how interactive and embed-focus our challenges are? Try some C/C++:Embed challenges on the learning platform today!

We sat down with Larry Maccherone at Contrast Security, the leader in modernized application security, embedding code analysis and attack prevention directly into software. We discussed how contextual learning successfully works to train developers in secure coding. 

Today’s developers are increasingly tasked with stopping tomorrow’s cybersecurity breaches. While training around code vulnerabilities may be available, it’s often offered in un-engaging formats that are not relevant to the developers' everyday work. Developers need to write code quickly to meet customer needs, pushing back business goals such as training. And when that training is provided out-of-context and in the form of long presentations or study manuals, it becomes even more daunting, making it hard to see the benefit of the extra effort. 

How can organizations provide key security training to developers without disrupting their daily responsibilities or keep them away from preferred tools and workflows? 

The answer is simple. By using contextual learning and delivering training right to developers’ fingertips. Larry discusses why this is so powerful for developers in the following video.

‍
By integrating training opportunities at the same time as developers are reviewing code issues, they receive the information that is most relevant to the identified issue or vulnerability immediately. Additionally, because the training is delivered in smaller and more digestible chunks, developers are more likely to retain the information and prevent the use of vulnerable code in the future. As Larry puts it, “feedback is the key to learning”.

The bottom line is that developers need to do more in less time and deliver secure, high-quality code. By weaving in training that’s contextualized and specific to the code vulnerability, it optimizes the developers’ workflows and experience, and increases their retention. Hear from Larry on how you can save those 40 hours of training!

‍
Secure Code Warrior offers technical integrations that deliver contextual and hyper-relevant learning to your development and security teams.

Interested in a demo? Book one below. 

‍

In life, generally, communication is a great thing. There’s no quicker way to come to an understanding, learn something new, or build a relationship. In the software space, APIs serve a communicative purpose that allows applications to talk to each other, boosting features and usability. That connectivity often creates a richer experience that end-users love, and increasingly, have come to expect from the software in their day-to-day lives. 

However, like in real life, it’s a big problem when they talk too much. Experian has recently found this out the hard way, when one of their APIs - used by a third-party partner - potentially leaked the credit scores of… well, just about every American citizen.

The problem was patched quickly, but questions remain on whether this vulnerability was truly stopped in its tracks. If one vendor was affected, chances are good that others were too, and there is the possibility that it is a systemic bug, affecting anyone making use of that insecure API.

API security is an issue that isn’t far from the minds of most security experts, and it’s something we need to equip ourselves with the knowledge to fight. 

Any swashbuckling geek can bypass poor API authentication

A feature of many data leaks, breaches, and security incidents, is that they rarely take a mastermind to achieve. Complex, insidious, damaging attacks like we saw with SolarWinds require teams of cybercriminal geniuses to carry out, and they are the exception rather than the rule. 

When an API is built with weak authentication, it’s rather easy for them to be exploited. Bill Demirkapi, the security researcher who discovered Experian’s API bug, determined that it could be accessed without any authentication. Inputting 00/00/0000 in the date of birth field granted him access to a person’s credit score, using only publicly available information like a name and associated mailing address. While this hasn’t been reported, the potential for these records to be scraped and contextualized as a credit-related data dump (and therefore valuable) is certainly there.

Clean and functional authentication processes should be in place no matter how small the use case; a chatterbox API that is not properly secured, and potentially opening up access to multiple systems, is a liability.

Broken Authentication is number two on the OWASP Top 10 API vulnerabilities list. Read more here on how you can avoid this bug, and test your skills on our platform once you’re done feeding your brain.

Poor API security controls are a widespread problem that requires cultural change

It’s not fair to point the finger solely at organizations like Experian, but the lack of nuance and security control diligence displayed in this particular API exposure doesn’t bode well for the many companies out there that are navigating APIs as part of their IT systems and endpoints. 

In general, we have a lot more work to do in not just finding and fixing API vulnerabilities, but understanding them as part of the attack surface we’re supposed to protect. Visibility over APIs - and how they have been built - is a huge concern, and it’s something that should be demanded as part of security best practices. Even an organization with the most stringent security measures can find itself undone by an API that is published and working outside of the company security controls. It is more important than ever to ask where an API has come from, who ultimately maintains it (is it a third-party vendor? How stringent are they with security?), and what information it is accessing. 

Injection vulnerabilities remain a barnacle for every CISO.

API security may seem like a fairly new module to include in a security program, but it can be exploited by some (very) old tricks we’re used to seeing in plain old web software.

A recently disclosed attack on Accellion revealed that chained SQL injection and OS command execution attacks allowed the threat actors to manipulate APIs, extracting a significant haul of sensitive data, including Social Security numbers. They determined that the attackers had to have had extensive knowledge of Accellion’s FTA software to carry out the heist, which would have been possible through substantial reverse engineering.

With the breach happening over December 2020 and January 2021, there was plenty of time for the thieves to cause damage. Further discoveries in February 2021 uncovered a stored XSS vulnerability, with forensic analysis finding that just one API endpoint having improperly sanitized user input made it possible to inject an argument when calling the admin.pl script. 

With over 3000 customers, including many prestigious educational institutions, this breach could be far-reaching. The unfortunate situation is that these exploits were made possible by leveraging common vulnerabilities, many of which could have been addressed at the code level, pre-production, by a security-aware developer. As we keep seeing time and time again, it only takes a small window left open to create big problems. And a culture of human-led cyber defense needs to be part of the strategy in solving a very human problem.

Want to test your API security skills now in Java Spring API, Kotlin Spring API, C# (.NET) Web API and more? Try some API challenges on our Learning Platform (check out all languages:frameworks via the drop-down):
‍

‍

The words “champion” and “coach” are finding increasing relevance outside of the sporting realm, and they carry a powerful presence in most contexts. There are life coaches, wellness coaches, empathy coaches, and “champions” who are being crowned in many organizations, titles like “safety champion” or “vibe champion” are becoming more mainstream and integrated into the spirit and culture of the business. When the going gets tough, who wouldn’t want a coach or a champion in their corner? 

Institutions within the cybersecurity industry have a long history of utilizing champions in the pursuit of spreading the good word about security at the development level, and upholding higher standards of software security. BSIMM calls them the Satellite group, while OpenSAMM and Axway are among the pioneering groups supporting security champions as a concept and formalized program. These initiatives intersect with and support one of the main objectives of the DevSecOps movement, which is a commitment to share responsibility for security across teams and functions, from the very beginning of the software development process.

Many companies who are kicking goals in their cybersecurity approach have implemented an official security champion program, bestowing key security responsibilities - everything from liaising between teams and general cheerleading, to overseeing best practices - onto individuals who show aptitude and passion for such a role. 

However, it has been rather evident that the role of the “security champion” is changing, and a forward-thinking company can reach new heights of scalable security best practices with an expanded team, with key enthusiasts supporting different, yet equally important functions. 

We’re redefining and duplicating the security champion to really make an impact in a future-proof security program. Are you ready to build your next Dream Team?

Every great team stands behind an inspirational coach.

When you think about Lionel Messi, Michael Jordan, and Serena Williams, typically only the most diehard fans would be able to recite facts about their coaches, however, it is that close pillar of support honing their natural skills, talent, and drive towards their goals that breeds the immense success we see in the spotlight. 

Nobody expects developers to win a grand slam or score a goal for Argentina, heck, nobody should even expect that developers will be security experts (after all, they signed up to create cool features, not take deep dives into security), but a great security “coach” is their true champion on the team.

A developer-side security champion is far more aligned to what we would recognize as the fundamentals of a coach. They are passionate about security, know their stuff, and are a key point of contact when a developer has a security issue to solve. They have the hands-on know-how to help them correct the problem and learn from their mistakes, while also making sure the team is aligned with core security best practices and values. 

Will the AppSec champion please stand up?

An AppSec-side champion is an oft-missing piece of the security program puzzle. They are absolutely vital for the success of a development team, and as the bridge between C-level and executive staff and the developers, can actively advocate for them and help enable them with the tools they need to make a positive impact on vulnerability reduction, software safety, and customer trust and satisfaction. 

A great AppSec champion is recognized as a security leader within the business, and they should have a big role in training the security coaches directly, with the end goal of forging better outcomes and relations between the teams, all in the aid of a common goal: kick-ass, watertight secure code. 

Summoning your supercoach.

Champions and great coaches go hand-in-hand, and together, they create magic. Existing security champion programs do tend to focus on the developer, but as we have identified, the real championing should be on the AppSec side, leaving the most passionate, security-aware developers to help achieve secure coding greatness under the hood, uplifting the rest of the team. 

Discovering the ideal coach is still a similar process to the traditional champion: the best coach is not simply the person who is “best” at security. The individual who happens to be amazing at coding securely and churning out high-quality, fortified code, may have zero interest in taking on an extracurricular role, or perhaps they aren’t particularly excited by security despite their aptitude. 

Instead, your coach might be uncovered if you look for someone who:

• Takes a keen interest in cybersecurity, from the hands-on coding through to staying up-to-date on the latest incidents, tools, and cool developments
• Has decent interpersonal skills; they enjoy helping others, feeling like the go-to person (or resident expert) and are approachable team players
• Can be proactive in developer-side advocacy; they know what is needed to help the team, and can work with their AppSec liaison (their champion) to have needs met so that mutual security outcomes can be achieved.

Incentivize the coach position; whoever you choose will have to take on more responsibility, and their workload will need to be assessed accordingly. While personal interest and career progression will factor into a potential coach’s motivation, it’s good practice to see where else they can be rewarded for kicking goals. Can they be sent to an awesome conference? Can they get some extra leave? Can courses and certifications be funded for them? Time and money spent now on securing the SDLC from the start saves much more later in the cycle - or worse, if a vulnerability is discovered live - and a good coach will keep awareness high. Find a way to provide meaningful rewards.

Your next-level security champion program.

Ultimately, as an industry, we must do more to support developers, and win them over to the dark security side, in so much as motivating them to see that quality code is secure code. It’s difficult to care about something when the time and effort to educate and enable success hasn’t happened, and sadly, that tends to be the case with education in secure coding. Relevant, hands-on upskilling, in conjunction with a peer coach and AppSec advocate, really is the triple-hit needed to bolster the development team to unleash their defensive power.

A version of this article appeared in Help Net Security. It has been updated and syndicated here.

‍

I have spent my career finding, fixing, discussing, and breaking down software vulnerabilities, one way or another. I know that when it comes to some common security bugs, despite being in our orbit since the 90s, they continue to plague our software and cause major problems, even though the (often simple) fix has been known for almost the same length of time. It truly feels like Groundhog Day, where we as an industry seem to do the same thing over and over and expect a different result. 

There’s another little problem, however. We’re not getting realistic advice, nor the fastest solutions, to combat the non-stop onslaught that is modern cybersecurity. Of course, each breach is different in its own way, and there are numerous attack vectors that can be exploited in vulnerable software. Feasible generic advice will be limited, but the best practice approach is looking more flawed by the hour. 

To this end, I do have to wonder why so much of the commentary and analysis around cybersecurity has omitted solutions that truly address the root cause of so many vulnerabilities: humans. Gartner’s most recent Hype Cycle for Application Security, and Forrester’s The State of Application Security 2021, both bibles for security experts that undoubtedly help to shape their program and potential product adoption, are almost entirely tools-focused. A report by Aberdeen back in 2017 showed just how unruly the average security tech stack had become, with CISOs managing hundreds of products as part of their security strategies; four years later, we’re grappling with more risk, more vulnerabilities, and more additions to growing tech stack beasts.

Security tooling is a must-have, but we need to look wider and restore balance to the people component of security defense.    

Automation is the future. Why should we care about the human element of cybersecurity?

Virtually everything in our lives is powered by software, and it’s true that automation is replacing the human elements that were once present in so many industries. It’s a sign of progress in a world digitizing at warp speed, with AI and machine learning hot topics keeping many organizations future-focused. 

So, why, then, would a human-focused approach to cybersecurity be anything other than an antiquated solution to a technologically advancing problem? The fact that billions of data records have been stolen in breaches in the past year, including the most recent Facebook breach affecting over half a billion accounts, should indicate that we’re not doing enough (or taking the right approach) to make a serious counter-punch to threat actors. 

Cybersecurity tooling is a much-needed component of cyber defense, and tools will always have a place. Analysts have been absolutely on point in recommending the latest tools in a risk mitigation approach for enterprises, and that will not change. However, with code quality (and, by definition, security) difficult to manage at the volume of code production, tools cannot do the job alone. To date, there is no single tool that will:

• Scan for every vulnerability, in every language:framework
• Scan at speed
• Minimize the double-handling caused by false positives and negatives

Tools can be slow, cumbersome, and unwieldy. Above all, however, they only find problems - they don’t fix them, or recommend solutions. The latter requires security experts, who are thin on the ground and overworked, wading through the trash to find treasure in endless pentesting and scanning results.

The fact is, according to the IBM Cyber Security Intelligence Index Report, human error plays a role in 95% of all successful data breaches. Almost half of those directly relate to software vulnerabilities, many of which could be alleviated if there was stronger adherence to secure coding and awareness in the early stages of the SDLC. However, for this to happen, a sharper and more relevant focus on education for developers - in addition to making it intrinsic to their workflow - is key. 

Whether we like it or not, humans are deeply ingrained in the software development process, and cybersecurity is overwhelmingly a human problem. Tools won’t be a catch-all to correct a fundamental flaw in our approach, but they can play a key supporting role in reshaping human solutions. 

What if we just built better tools (and lots of them)?

Security tooling is improving all the time. SAST/DAST/IAST tools have come a long way, improving in speed and intelligence, and RASP should be a serious defensive consideration in many application environments. Firewalls, secrets managers, cloud and network security applications: all no-brainers. 

Humans can always strive to make better tools, but the innovation is not keeping up with the security and data protection needs of the digital world we live in. Tools are, for the most part, built with robots in mind. They might be there to assist developers and the security team in scanning, monitoring, or protecting code, but interaction is very limited, and very few solutions aim to elevate security awareness or improve core skills that can lead to better security outcomes.

In fact, more than half of enterprises don’t even know if the tools are working for them, nor are they confident that they could avoid a devastating data breach. That’s a very poor sentiment, and in a tools-obsessed industry lacking support for a different approach, tends to solidify the status quo and the problems within. 

How can an organization leverage a human-led approach to security?

There is no question that staying ahead of the trends in application security technology is beneficial, and can even help prioritize upgrades or consolidations in a bloated tech stack, but to forgo targeting the root cause of vulnerable software - we mere humans - is going to keep us on the losing side of the cybersecurity battlefront.

If we want to get serious about decreasing the number of code-level security vulnerabilities, then developers need to be given the foundations to succeed in sharing responsibility for security. They need relevant, hands-on education and on-the-job upskilling, and functional tooling that doesn’t disrupt their workflow, or make security a chore to develop. Ideally, some tools would be developer-centric, built with their user experience front-of-mind. 

To this day, no formal security certification program exists for developers, but every company can benefit from benchmarking and growing secure coding skills, killing common vulnerabilities early and often, and before that big tech stack has to lurch into action and slow everything down. 

A team of security-aware developers is a hidden treasure for any organization, but like anything worth having, it will take time and effort to implement an effective dream team. Winning developers over to care about security, and view secure coding as a foundation of code quality, takes an organization-wide commitment to put security first. And when entire teams are switched on to the positive impact they can play in eliminating common vulnerabilities as code is written, there isn’t a tool on Earth that can compete.

We were recently very excited to see the first Forbes Technology Council post by our chairman and CEO, Pieter Danhieux, go live. The post detailed how upskilling developers to create more secure code is a key to preventing cyberattacks and data breaches. Not only that, it revealed how these same security-aware developers can assist in delivering better, more secure code, faster than many IT departments realize. The need for this approach is certainly compelling. A recent study found that a cyberattack now occurs every 39 seconds, and we have all seen the disruption caused by just one successful ransomware attack on the Colonial Pipeline, which in the larger scheme of things wasn’t as destructive as the SolarWinds hack. 

‍

Many common vulnerabilities continue to exist because no one ever bothered to show developers how to replace poor coding patterns with a better way of accomplishing the same functions, in a safer and more secure way. And the impact of fixing software late in its development is extremely costly both in terms of hours spent and delays to deployment. Fixing the code after it’s been deployed, especially after an attacker has exploited a previously undiscovered vulnerability, can sometimes cost millions of dollars. And that doesn't even take into account damage to a company’s reputation following a major breach.

Security-trained developers naturally become better coders. Certainly, CISOs shouldn’t drop their security tooling anytime soon, but by leading an inclusive, preventive security approach from the top, CISOs can take advantage of their company’s greatest resource, the human factor, especially when it comes to secure coding from the very beginning of the software development lifecycle.

To do this, here are the top three high-level strategies to keep in mind.

1. Be proactive, not reactive

Businesses often fall into the trap of being reactive, for example, responding to what the competition does instead of developing and pursuing a unique vision. Many also default to this approach when it comes to security vulnerabilities in code, taking cybersecurity seriously only when compelled to as a result of a successful breach. Unfortunately, by then the damage is done, with fines, recovery costs, customer attrition, and brand restoration all hitting the bottom line. Another form of reaction instead of action is relying on automatic or manual code scanning to find vulnerabilities in existing code instead of focusing on creating secure code in the first place. Unfortunately, code scanning is not a perfect solution, which means that the more vulnerabilities there are in the code, the greater the chance that some will slip through. 

Only by taking a proactive approach and working with developers to help them create secure code from the start can you establish a software development life cycle that significantly reduces the possibility of coding vulnerabilities being released to users.

2. Upskill, don’t overkill

Once you decide to provide developers with the knowledge they need to create secure code, choose your approach wisely. In-house training workshops that bring coding to a halt frustrate developers and managers alike. Offsite courses that require evening or weekend attendance are even less popular. The best approach is to build coding skills incrementally, providing relevant information step-by-step during the coding process – essentially upskilling without significantly distracting developers or slowing the development process. 

3. Incentivize, don’t assume

Developers should not see security upskilling as punishment or a total drudgery. Managers must inspire developers by communicating the important role that secure code plays in the success of the company. It’s also important to convey that secure coders are more valuable to the company and will enjoy expanded career opportunities in the future.

The Biden Administration’s welcomed Executive Order has amped up the focus on cybersecurity and the need to “include criteria to evaluate the security practices of the developers and suppliers themselves, and identify innovative tools or methods to demonstrate conformance with secure practices.” But while tooling is essential, it isn’t enough. No tool will ever completely eliminate an individual’s ability to somehow ignore, misunderstand, abuse or otherwise get around the systems and tools that have been put in place. To maximize the security of their companies, CISOs must take advantage of the human factor and encourage developers to become willing security proponents and practitioners.

The recent cybersecurity Executive Order from the Biden Administration has certainly got the security industry talking, especially those who are looking to win over developers to the importance of applying secure coding best practices in their day-to-day work. For the first time, developers who are working on software in use by the federal government must have verified security skills, as well as adherence to new, evolved guidelines. 

This marks a positive change in the cyber defense status quo, and finally makes adequate upskilling of developers part of the conversation. While these policies are US government-centric, they offer a global opportunity for organizations to address and upgrade current security standards, everything from developers to security analysis of software supply chains. 

NIST recently sought public comment to inform their next updates to HIPAA legislation, among others, and this was an unmissable opportunity for us to pool our company expertise into positioning papers that can help inform a safer, and more effective, human-led approach to cybersecurity that will help organizations leverage their teams for greater outcomes. 

As an expert-driven organization, we are fortunate to have some of the most dedicated and accomplished cybersecurity professionals working with us, including Ph.D. candidate Pieter de Cremer, and Dr. Brian Chess, who is part of our Technical Advisory Board. The three of us put our heads together to formally submit positioning papers to NIST, calling out ways our approach to developer upskilling and preventative security at the software creation stage could positively impact cybersecurity standards going forward. 

A secure development pathway, paved for developers

Vulnerability scanning tools, monitoring and other forms of security automation are increasingly prevalent, and they feature in both the new Executive Order, as well as within NIST guidelines. They are an increasingly essential part of a modern security program, but history and the present show that scanning tools in particular certainly find vulnerabilities in software with ever-increasing efficiency, yet this alone has no effect on reducing them, or, indeed, improving security from the start. 

A cumbersome tech stack that is distracting and slows down the developer workflow is one of the fundamental reasons that developers disengage with security and view it in a negative light. However, if developers had a paved pathway for secure development, one that was customized to suit not just the technology, but also languages, frameworks, and project-specific development objectives, then embedding security into the development process from the beginning - with as little disruption to their productivity as possible - is an ideal that would result in significant reduction in common vulnerabilities over time. 

To read our NIST positioning paper in full, download it now:

Certification framework for secure development practices: The (current) missing link

To date, there is no formal certification to verifying secure coding skills and best practices. This has been an industry oversight for a long time, and it’s our position that this is essential for the future of improved cyber defense and secure development. 

We know there are many forms of security training targeting developers, but if the volume of large-scale data breaches, cyberattacks, and poor quality code out there is any indication, it’s not creating security-aware developers, and they are not being equipped with the knowledge to make a dent in a problem that is only getting worse. 

Developer upskilling requires tools and education that is day-job relevant, contextual, bite-sized (yet frequent), and allows them to build upon existing knowledge in the languages and frameworks they actually use. Generic training does not suffice, and this needs to be made abundantly clear in legislation and industry bodies such as NIST. 

The NICE Framework is more than suitable to build out comprehensive certification guidelines that actively use methodologies that work, and are of most interest and relevance to developers, and their work. Aligning with this recognized institutional framework helps to standardize practices that truly make a difference, and provides more concrete pathways for organizations to follow. 

To read our second NIST positioning paper in full, download it now:

The people factor in cybersecurity is often forgotten, and it’s time we worked towards human solutions for human problems such as recurrent common vulnerabilities. Decades-old bugs should no longer trip us up, but it will take the backing of global governments to change the status quo and provide measurable, positive impact. 
‍
Are you ready to certify your developers? You’ve come to the right place. Check out our Learning Platform today.

We recently sat down with Dimitri Vanderhaeghe, Software Engineer at Selligent Marketing Cloud, a highly integrated, AI-powered omnichannel marketing automation platform that enables ambitious B2C marketers to maximize every moment of interaction with today’s connected consumers.  For Selligent, a fast-paced B2C technology company scaling up and meeting the growing demands of their market is vital. Part of being able to meet these demands is an emphasis on cybersecurity and most crucially a developer-led, security skills program. 

Why is cybersecurity vital for scaling your business? 

A strong security strategy has to be high on your company's agenda if you want to scale your business, otherwise you leave yourselves open to vulnerabilities. A cybersecurity attack takes place every 39 seconds, and the cost of an attack on your business can be financially detrimental and ruin your reputation. We only have to look to the Equifax hack in 2017 for a prime example as their CEO resigned and made it clear that the hack was the reason for doing so. 

However, cybersecurity has to become a shared responsibility in order to scale, in particular within your developer community as Dimitri explains:

"The most important reason to train engineers is scalability, because we have a big product that almost 60 engineers are working on. If they don't care about security, all the vulnerability scans come back to the security specialists."

How do you create a developer-led security culture?

Dimitri and the Selligent team seem to have cracked a developer-led security culture, but from our recent research only 15% of developers see security as everyone’s responsibility within their organization. So, how do you start left and create a developer-led security culture?

Dimitri attributes this to an increase in security awareness generated through Secure Code Warrior® 's learning platform to upskill their developers. Dimitri says that without the platform they would have struggled to create security awareness. As a result, security is at the forefront of the developers’ minds when producing code. 

Another key aspect to creating a developer-led security culture is to make training relevant. Our recent study also showed that 40% of developers say that training is not hands-on and 30% say it’s also not relevant Dimitri notes that the granularity and real-world nature of Secure Code Warrior® tournaments make all the difference. The fun and competitive nature of the platform also leads to more engaged and aware developers. 

As Dimitri points out, without awareness the burden of cybersecurity falls back to the security specialists, which simply is not scalable. The answer is to scale your business and products effectively to ensure you’re protected against software vulnerabilities by focusing on hyper-relevant contextual training of your developer community with a developer-led security skills program. 

‍
Secure Code Warrior can offer your organization just that. Interested in a demo? Book one below. 

‍