Unlike attacks aimed squarely at website or application operators, the goal of many Cross-Site Request Forgery (CSRF) attacks is to steal money, goods or credentials directly from a user. This does not mean that site operators should ignore CSRF code vulnerabilities, as ultimately the replacement of stolen funds, in the case of a purely monetary attack, may be the responsibility of the hosting site with the insecure code. And if the targeted user instead loses their credentials or has their password unknowingly changed, a criminal might be able to wreak havoc using that stolen identity, especially if the victim has privileged access.

CSRF attacks are fairly complex and rely on multiple layers to be successful. In other words, lots of things have to break in favor of the attacker for it to work. Despite this, they are an extremely popular attack vector because a successful attack can transfer money directly to a hacker, or set them up to be able to move about a site with impunity. If everything goes a hacker's way, the targeted user may never even know that they fell victim to an attack.

The good news is that because so much has to go right for a CSRF attack to work, there are quite a few great defensive techniques that can halt them in their tracks.

To that end, we'll discuss three key aspects of CSRF attacks:

• How they work
• Why they are so dangerous
• How you can put defenses in place to stop them cold.

How do CSRF attacks work?

Because successful CSRF attacks have the ability to directly steal money, goods or credentials from targeted users, they are popular despite the high amount of work that must go into creating them. And because they are often attempted on different platforms, over the years they have picked up a variety of names and monikers. You might hear CSRF attacks referred to as XSRF, Sea Surf, Session Riding, Cross-Site Reference Forgery or Hostile Linking. Microsoft likes to refer to them as One-Click attacks in most of its documentation. But they are all CSRF attacks, and the techniques to defeat them are identical.

A CSRF attack can happen if a user is logged into a site conducting business or doing their work. The key is that the user must be logged in and actively authenticated to a website or application. The attack is normally launched from a secondary website or an e-mail. Oftentimes attackers use social engineering techniques to trick users into clicking on a link in an e-mail that takes them to a compromised website with the attack script.

The compromised website contains a script that instructs the active browser to execute commands, normally something malicious like changing a user's password or transferring money to an account controlled by the attacker. As long as the user is authenticated, the site will think that the commands are being issued by the authorized user. Why wouldn't it? The user has already authenticated themselves and provided whatever passwords are required to access the site. They may even be located within a geofence, properly sitting at their office terminal. If they want to change their password or transfer funds, there is no reason not to believe that it's them making the request.

Breaking down the elements of the attack, it's clear why this one is so difficult to pull off for the attacker. For starters, the user must actively be authenticated with the site where the attack takes place. If an e-mail with an attack script comes in after a user has ended their browser session, or logged off, the attack fails.

The attacker is also forced to perform a lot of recon on the targeted site in order to know what scripts that site will accept. Attackers can't see a victim's screen, and any feedback from the website will go to the victim, not the attacker. Unless the attacker is able to see evidence of their attack working, such as money suddenly showing up in their account, they won't even know right away if it has been successful.

Within the difficult-but-not-impossible parameters of having the user logged in at the time of the attack and knowing what scripts the targeted site will accept, the code to execute a CSRF attack can be extremely simple, though it varies depending on the site itself.

Let's say a bank or finance application uses GET requests to transfer money, like this:

GET http://bank.com/transferdo?acct=NancySmith12&amount=100 HTTP/1.1

That code would send a request to transfer $100 to a user named NancySmith12.

But if the targeted user got an e-mail, perhaps one disguised as coming from a colleague, a CSRF attack script could be embedded in the click action:

<a href="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000">Can you quickly read over this quarterly report?<a></a></a>

If the targeted user fell for the social engineering link and clicked on it while the browser session with the finance application was still open, their browser would ask the application to send $100,000 to ShadyLady15's account.

The script could even be hidden in an invisible image that the user would not see, but which could still trigger the browser to make the request, like this:

<img src="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000" width="0" height="0" border="0">

The result is the same. ShadyLady15 gets $100,000 without anyone detecting the attack.

Why is CSRF so dangerous?

CSRF attacks are popular today for the same reason that ransomware attacks continue to make the rounds. It puts very few hops between attackers and a victim's money. In a ransomware attack, systems are encrypted and users are extorted for money to decrypt that data. With a CSRF attack, it's even fewer steps. When they work, victims simply send money to attackers without knowing it.

Beyond direct attacks on a victim's money or a company's finances, successful CSRF attacks can be used to compromise a network using valid users. Imagine if an attacker could use a CSRF exploit to change an administrator's password. They could immediately use that password to begin stealing data, open up holes through network defenses or install backdoors.

Although it's a lot of work, and to some extent luck, a successful CSRF attack can be like winning the lottery for hackers regardless of their ultimate goal. When attacking a network, almost any other kind of attack would require months of low and slow reconnaissance, trying to keep below the radar of the SIEM and cybersecurity staff. By contrast, a single CSRF attack can skip quite a few steps along the cyber kill chain, letting them start very close to their ultimate goal.

How Do I Stop CSRF Attacks?

Unlike most vulnerabilities, with CSRF attacks the fault is not really with the code, but with an exploit that attackers have created to force a browser to make requests that a user doesn't want, and may not even know about. But they can be defeated.

One of the best methods is to have developers add a CSRF token to a user's identity whenever a new session is generated. It should consist of a string of unique and random characters and be invisible to users. Next, add the CSRF token request as a hidden field to forms that are checked by the server whenever a new request is submitted. Attackers submitting requests through a user's browser won't even know about the hidden token field, much less be able to find out what it is, so all of their requests will fail.

An even easier method, and one that does not require very much programming, is to add a Captcha challenge to anything sensitive like password change requests or money transfer orders. It can be as simple as asking a user to click one button confirming that the requestor is not a robot, or in this case, a CSRF script. Attackers won't be able to script a response to the challenge, and users who suddenly get a CAPTCHA challenge without first doing something like making a money transfer request will know that something is up. Alternatively, one-time password generation using a third party token, like a smartphone, can be used, depending on how much an organization wants to slow down work in the name of security.

Finally, though it is not ironclad, many browsers like Microsoft Edge or Google Chrome now have same-origin policy restrictions in place to block requests from anyone but the local user. Forcing users to interact with your site using the most updated versions of those browsers can help to build in another layer of CSRF security without taxing development teams at all.

Slamming the Door on CSRF

With such a high potential payout, CSRF attacks will likely never fully die, but we hope you learned why they are so persistent, and how to block them from your network for good.

For further reading, you can take a look at the OWASP Cross-Site Request Forgery Prevention Cheat Sheet, which serves as a living document chronicling this vulnerability as it evolves. If you'd really like to bolster your security knowledge, you can learn to defeat this threat and many more by visiting the Secure Code Warrior blog.

Think you're ready to put your new defensive knowledge to the test? Play around with the free demo of the Secure Code Warrior platform today.

Cross-site scripting (XSS) has been a bugbear for security professionals since the early 2000s, and sadly, decades on, it still registers as one of the most common code-level threats. This class of software vulnerability has plagued us for far too long, and a recent alert from CISA - as part of their Secure-by-Design movement - is seeking to thwart it once and for all. They are on a global mission to eliminate vulnerability classes at scale, and this spotlight on developer-driven security is something that can really move the needle and make a difference, but it's going to take commitment from smart enterprises who set their developers up for security success.

So, what is XSS, exactly?

Web browsers might be our gateway to all that great stuff online, but sadly, it's not all good news. The inherent behavior of web browsers can be a catalyst for security vulnerabilities. Browsers began by characteristically trusting the markup it saw and executing it without question. That's all fine and dandy until that functionality is exploited for unsavory purposes... and naturally, attackers eventually found ways to exploit this tendency to further their evil ends.

Cross-site scripting uses the trust of browsers and ignorance of users to steal data, take over accounts, and deface websites; it's a vulnerability that can get very ugly, very quickly.

Let's take a look at how XSS works, what damage can be done, and how to prevent it:

How does XSS work?

XSS occurs when untrusted input (often data) is rendered as output on a page but misinterpreted as executable code. An attacker can place malicious executable code (HTML tags, JavaScript, etc.) within an input parameter, which -- when returned back to the browser -- is then executed instead of displayed as data.

As mentioned above, the vulnerability appeared due to the core functioning behavior of browsers, where it is difficult to distinguish data from executable code. The operating model of the web is as follows:

1. User visits a web page
2. The page tells the browser what files to load and what to execute
3. The browser executes what is on the page, no questions asked

This functionality has led to some of the most awesome, interactive experiences we enjoy on the web. The other side of the coin is that it has also led to costly exploits and vulnerabilities.

When attackers add their malicious script to a vulnerable site, it is executed without question. There is no deeper investigation, nor detection measures in place.

There are three types of XSS:

• Stored XSS
• Reflected XSS
• DOM XSS

Stored XSS occurs when an attacker can persistently store the malicious script in a data field of the application (e.g. in a field that stores the user's mobile phone number). This sketchy script is then sent to a user's browser every time that data field is displayed in the application.

This type of attack is often seen on forum sites or commenting engines. An attacker enters the malicious script in a comment, and bam - every user who views that comment unknowingly executes the script.

Reflected XSS occurs when user input is reflected back to the user's browser as-is. An example is a search box that displays, "You searched for ..." to the user while fetching search results.

Now, imagine that the search works by placing the search term in the URL as query parameters. A malicious attacker could send the victim a link with the malicious script embedded in those very same parameters and truthfully, most web users would barely notice it.

The victim clicks the link and is redirected to a phishing site where he/she unwittingly enters their password for the site. Little do they realize, an attacker has just stolen the key to their account.

DOM XSS is a relatively new variety of this vulnerability. It takes advantage of complex templating structures found in many UI frameworks such as Angular and React.

These templates allow for dynamic content and rich UI applications. If used incorrectly, they can be used to execute XSS attacks.

So, there you have it. You've got the scope of XSS in a nutshell. Let's dive deeper into how it can be used destructively.

Why is XSS so dangerous?

XSS can be used to redirect users to malicious sites, steal cookies and hunt for session data. Basically, whatever JavaScript can do, XSS attacks are capable of as well.

Here are three examples of XSS attacks:

1. Yahoo email users had their session cookies stolen using XSS in 2015.
2. The Samy worm was distributed via an XSS vulnerability in MySpace. It is still the fastest-spreading malware of all time, affecting one million users in just 20 hours.
3. eBay allowed malicious scripts to be included in product descriptions. This led to XSS attacks against eBay users.

XSS attacks are deceptively simple and very serious. They can lead to the theft of sessions, user credentials or sensitive data. Reputational damage and decreased revenue are major pitfalls of these attacks. Even just defacing a website can lead to undesirable consequences for a business.

However, XSS can be defeated by a savvy security warrior just like you. The fix is not complicated and the industry has come a long, long way since XSS became a commonly used exploit.

You can defeat XSS.

The key to defeating XSS is understanding the context. Specifically, the context in which your user input will be rendered back to the client and where it will be rendered back. Inside the HTML code, or inside a JavaScript snippet.

If user input doesn't have to be sent back to the browser, so much the better. But if it is, it often should be HTML-encoded. HTML encoding the output will tell the browser to render the content as-is and not to execute it.

Input validation is important as well. However, validation and whitelisting are not foolproof solutions. Encoding goes a few steps further and stops browsers from executing a malicious script. Whatever is not caught with validation and whitelisting strategies, encoding will pick up.

Many frameworks are now encoding HTML output automatically.
Angular, ASP.NET MVC, and React.js are frameworks where default HTML encoding is used. You have to specifically tell these frameworks not to encode by calling a special method.

Most other frameworks, (i.e. Django and Spring) have standard libraries for XSS prevention that you can easily incorporate into your code.

The biggest challenge is teaching yourself to analyze all of the ways that user input can enter a system so you can keep your eyes peeled for it. Query parameters can carry attacks, as can post parameters. Follow the flow of data throughout your application and do not trust any data that comes from outside.

Think like border patrol. Stop every piece of data, inspect it, and don't allow it in if it looks malicious. Then encode when rendering to ensure that any bad stuff that was missed still won't cause problems.

Execute these strategies, and your users will be safe from attack via XSS. Take a look at the OWASP Cheat Sheet for even more tips to keep your data under control.

Thwart XSS and level up your security skills.

XSS resides at number seven on the OWASP Top 10 2017 list of web security risks. It has been around for a while, but it can still appear and cause problems with your application if you're not careful.

Training is so important for developers in building a security-first mindset as they craft code. And, that training is always at its most effective when it simulates real applications, in the languages developers are actively using. With that in mind, why not check out our Learning Resources to learn more about XSS? After that, you can begin the training and practice that leads to your mastery.

Think youre ready to find and fix XSS vulnerabilities right now? Challenge yourself on the Secure Code Warrior platform.

In simple terms, SQL (or Structured Query Language) is the language used to communicate with relational databases; it's the query language used by developers, database administrators and applications to manage the massive amounts of data being generated every day.

Our data is fast becoming one of the world's most valuable commodities... and when something is valuable, bad guys will want to get their hands on it for their benefit.

Attackers are using SQL injection -- one of the oldest (since 1998!) and peskiest data vulnerabilities out there -- to steal and change the sensitive information available in millions of databases all over the world. It's insidious, and developers need to understand SQL injection (as well as how to defend against it) if we are to keep our data safe.

To that end, we'll discuss three key aspects of SQL injection:

• How it works
• Why it's so dangerous
• How to defend against it

Understand SQL Injection

SQL injection can be understood by using one word: context.

Within an application, two contexts exist: one for data, the other for code. The code context tells the computer what to execute and separates it from the data to be processed.

SQL injection occurs when an attacker enters data that is mistakenly treated as code by the SQL interpreter.

One example is an input field on a website, where an attacker enters ‘’’ OR 1=1" and it is appended to the end of a SQL query. When this query is executed, it returns "true" for every row in the database. This means all records from the queried table will be returned.

The implications of SQL injection can be catastrophic. If this occurs on a login page, it could return all user records, possibly including usernames and passwords. If a simple query to take data out is successful, then queries to change data would too.

Let's take a look at some vulnerable code so that you can see what an SQL injection vulnerability looks like in the flesh.

Check out this code:

String query = "SELECT account balance FROM user_data WHERE user_name = "
+ request.getParameter("customerName");
try {
   Statement statement = connection.createStatement( ... );
   ResultSet results = statement.executeQuery( query );
}

The code here simply appends the parameter information from the client to the end of the SQL query with no validation. When this happens, an attacker can enter code into an input field or URL parameters and it will be executed.

The key thing is not that attackers can only add ‘’’ OR 1=1" to each SELECT query but that an attacker can manipulate any type of SQL query (INSERT, UPDATE, DELETE, DROP, etc.) and extend it with anything the database supports. There are great resources and tools available in the public domain that show what is possible.

We'll learn how to correct this issue soon. First, let's understand how much damage can be done.

Why SQL Injection is So Dangerous

Here are just three examples of breaches caused by SQL injection:

• Illinois Board of Election website was breached due to SQL injection vulnerabilities. The attackers stole the personal data of 200,000 U.S. citizens. The nature of the vulnerability found meant that the attackers could have changed the data as well, although they didn't.
• Hetzner, a South African website hosting company, was breached to the tune of 40,000 customer records. A SQL injection vulnerability led to the possible theft of every customer record in their database.
• A Catholic financial services provider in Minnesota, United States, was breached using SQL injection. Account details, including account numbers, of nearly 130,000 customers were stolen.

Sensitive data can be used to take over accounts, reset passwords, steal money, or commit fraud.

Even information not considered sensitive or personally identifiable can be used for other attacks. Address information or the last four digits of your government identification number can be used to impersonate you to companies, or reset your password.

When an attack is successful, customers can lose trust in the company. Recovering from damage to systems or regulatory fines can cost millions of dollars.

But it doesn't have to end that way for you.

Defeat SQL Injection

SQL injection can be defeated by clearly labeling parts of your application, so the computer knows whether a certain part is data or code to be executed. This can be done using parameterized queries.

When SQL queries use parameters, the SQL interpreter will use the parameter only as data. It doesn't execute it as code.

For example, an attack such as ‘’’ OR 1=1" will not work. The database will search for the string "OR 1=1" and not find it in the database. It'll simply shrug and say, "Sorry, I can't find that for you."

An example of a parameterized query in Java looks like this:

Most development frameworks provide built-in defenses against SQL injection.

Object Relational Mappers (ORMs), such as Entity Framework in the .NET family, will parameterize queries by default. This will take care of SQL injection without any effort on your part.

However, you must know how your specific ORM works. For example, Hibernate, a popular ORM in the Java world, can still be vulnerable to SQL injection if used incorrectly.

Parameterizing queries is the first and best defense, but there are others. Stored procedures also support SQL parameters and can be used to prevent SQL injection. Keep in mind that the stored procedures must also be built correctly for this to work.

// This should REALLY be validated too
String custname = request.getParameter("customerName");
// perform input validation to detect attacks
String query = "SELECT account_balance FROM user_data WHERE user_name = ? ";

PreparedStatement pstmt = connection.preparedStatement( query );
pstmt.setString(1, custname);
ResultSet results = pstmt.executeQuery( );

Always validate and sanitize your inputs. Since some characters, such as "OR 1=1" are not going to be entered by a legitimate user of your application, there's no need to allow them. You can display an error message to the user or strip them from your input before processing it.

In saying that, don't depend on validation and sanitization alone to protect you. Clever humans have found ways around it. They're good Defense in Depth (DiD) strategies, but parameterization is the surefire way to cover all bases.

Another good DiD strategy is using "least privilege'within the database and whitelisting input. Enforcing least privilege means that your application doesn't have unlimited power within the database. If an attacker were to gain access, the damage they can do is limited.

OWASP has a great SQL Injection Cheat Sheet available to show how to handle this vulnerability in several languages and platforms... but if you want to go one better, you can play a SQL injection challenge in your preferred language on our platform right now; here's some of the more popular ones to get started:

SQL injection in C#

SQL injection in Node.js

SQL injection in Python Django

SQL injection in Java Spring

The Journey Begins

You've made some great progress towards understanding SQL injection, and the steps needed to fix it. Awesome!

We've discussed how SQL injection occurs; typically with an attacker using input to control your database queries for their own nefarious purposes.

We've also seen the damage caused by the exploitation of SQL injection vulnerabilities: Accounts can be compromised and millions of dollars lost... a nightmare, and an expensive one at that.

We've seen how to prevent SQL injection:

• Parameterizing queries
• Using object relational mappers and stored procedures
• Validating and whitelisting user input

Now, it's up to you. Practice is the best way to keep learning and building mastery, so why not check out our Learning Resources on SQL injection, then try our free demo of the platform? You'll be well on your way to becoming a Secure Code Warrior.

With 2020 seeing an enormous spike in remote working, plus continued large-scale data breaches and an increasing focus on the consequences of compromised privacy online, there has never been a sharper public focus on cybersecurity. As a result, governments around the world have stepped in to reshape and update their cybersecurity plans and infrastructure, including strategies and regulations that businesses are required to follow when handling our most precious digital resources.

Strategic protection guidelines for cybersecurity are not a new concept, and organizations like NIST have informed the policies of global government departments for many years. As we have moved through digital advancement at a cracking pace, it has become difficult for many to keep up with the number of threats, possible attack vectors, and compliance requirements that are part of an ever-changing landscape.

A recent breach of 54,000 New South Wales driver's licenses as a result of an easily accessed, misconfigured S3 bucket on a third-party server has compromised thousands of individuals, with the security researcher who reported it conceding that the data may already have been sold on the dark web. The sad thing is, this is an easy fix and would have been unlikely to happen at all had security been front-of-mind for those configuring the cache.

The Australian Government recently released the Australian Cyber Security Strategy 2020, highlighting new initiatives and a $1.67B funding boost to be used over the next decade, to achieve their "vision of creating a more secure online world for Australians, their businesses and the essential services upon which we all depend". This is clearly a very welcome review and updated plan, especially since one of the chief objectives is:

"Action by businesses to secure their products and services and protect their customers from known cyber vulnerabilities".

While government bodies tend to focus on (as they should) the security measures concerning a country's critical infrastructure -- areas that are ripe for a catastrophic organized attack -- what was lacking in the past were guidelines for the companies that collect and use our data every day.

Now, when it comes to official strategy like this, it's not always beer and Skittles. It can be a little hard to interpret, and vague on the details, leaving it up to an organization's security team to piece together a plan based on non-specific guidelines. This issue is not unique to Australia's government, but let's analyze their brand new release.

A focus on reaction, not prevention.

The updated Australian Cyber Security Strategy is a more relevant uplift to the last release in 2016, with fairly comprehensive plans for businesses, especially SMEs. The strategy outlines:

"Government and large businesses will assist small and medium enterprises (SMEs) to grow and increase their cyber security awareness and capability. The Australian Government will work with large businesses and service providers to provide SMEs with cyber security information and tools as part of "bundles'of secure services (such as threat blocking, antivirus, and cyber security awareness training)."

This will provide SMEs with a decent basic foundation on which to protect their business from cyber threats, but it is largely a reactive approach, and the focus is on detection tooling - a relatively small part of the cybersecurity landscape.

There is also surprisingly little information on how large enterprises can protect themselves and reduce their attack vectors. While many may be part of the plans to protect critical infrastructure (such as telecommunications, transportation), financial services, retail, and many other verticals have a lot to lose when it comes to a successful cyberattack. Perhaps this will be part of forthcoming legislation, but even so, highlighting the importance of meticulous cybersecurity best practices at the enterprise level is fundamental to seeing significant change, and a drop in compromised data and cybercrime.

Overall, when considering the strategy as a whole, it is built around a reactive approach. Countering cyber attacks, disrupting active cybercriminals and ensuring their prosecution, as well as intelligence sharing with international allies, are all important factors, but imagine if the nation-wide standard for protection was focused on prevention. Along with protective measures for critical infrastructure, if security was front-of-mind in every business, and every person touching the code that creates our digital world was properly equipped to block attacks before they happen, the savings in time, money, and heartache for victims is immeasurable.

Resilience is possible, but it must be planned.

It is clear from the Australian Government's push to get serious about cybersecurity that it has been identified as a key risk area on a national level. Like any other malicious attack that has the ability to disrupt our way of life, resilience is absolutely crucial - not just to withstand such an attempt, but to act as a deterrent to it happening at all. At the end of the day, even threat actors can be lazy, and they will move to an easier target to achieve their goal if too many barriers are put in the way of their success.

At the moment, we face a global cybersecurity skills shortage, and this is something that keeps CISOs around the world awake at night. Billions of lines of code, constant large-scale data breaches, and more risk of penalty (Marriott alone received a USD $123M GDPR fine for their 2018 data breach... and they had another breach this year) than ever before has created a demand chasm for security specialists that, realistically, is unlikely to be closed. There is simply too much code, and too little resources to ensure it is fortified from every angle.

So, should we give up on the idea that we will ever truly stand tall in the face of cyber threats? Not a chance. Resilience requires using all available resources, and thinking one step ahead. And for many companies, their developers can unlock a powerful method of fortification right as code is written. When paired with a visible, positive security culture across the whole business, this provides a secure foundation that is difficult for many attackers to shake and break. However, this method requires taking the suggestions from the Australian Cyber Security Strategy, as an example, and diving deeper into how they can be customized to support effective change that is relevant to the business.

To that end, it is important to break down a couple of the tips:

• Security awareness training: This is specifically called out for SMEs, and in the context of the whole report, is mainly aimed at teaching all staff basic security hygiene (e.g. spotting phishing emails, not clicking unknown links, etc.). Realistically, it must go much further than that and become role-specific, especially for those who touch code, like developers. It is imperative that security awareness training is a component of preventative measures and building resilience
• Education: In a refreshing change, there is an in-depth plan to address the cybersecurity skills shortage over the next decade, by way of emphasis on cybersecurity training from primary and secondary school, through to tertiary education. This is sorely needed if we are to build the security superstars of the future, but from a perspective of addressing business needs right now, hands-on training in secure coding for the development cohort is an absolute necessity to start reducing common vulnerabilities, and must be part of a functional security program.

As security experts, we need to do more to help companies all over the world understand the importance of building an internal security program that goes beyond simple foundational measures of awareness. Spending time to upskill developers takes the pressure off overworked AppSec specialists, and ensuring the entire organization is as security-aware as possible within the context of their role is vital in reducing the threat surface attack area in software.

Developer upskilling is time well spent, so why are so many companies ignoring it?

A recent survey by DDLS concluded that there is very little sense of priority when it comes to cybersecurity training in Australian organizations. In fact, it didn't even make the top three training priorities, despite 77% of respondents ranking cybersecurity awareness as "extremely" or "very important" in their business.

It's little wonder, then, that Australia is struggling to close the widening skills gap, and has some work to do to create a more resilient infrastructure, from essential services to retail, and everything in between.

There is an enormous opportunity here for governments to create a security skills baseline certification, or regulation, and the strategy alludes to this as a way to work with finite resources. However, once again, this seems to be a future-state proposal, and we have the tools to start much sooner if we target high-impact areas first. For me, the beacon of hope lies in the development teams within each organization, and given the tools and knowledge to succeed, they can cut off common vulnerabilities at the pass and significantly reduce the risk of a data breach within their organization.

In 2019, 24% of all data breaches were caused by human error - namely security misconfigurations - which are usually relatively simple, code-level fixes. If training is made a priority here, in conjunction with building company-wide security awareness, I'm betting that there would be fewer CISOs signing off on breach notifications to thousands of compromised customers.

June 23rd is a special entry in the geek calendar, marking International Women in Engineering Day. Though we should always celebrate the achievements of our peers and teams year-round,  this is our chance to cast light not just on the contribution of women to software development in general, but also their positive impact at Secure Code Warrior. We are very fortunate to have near-parity between males and females in our organization, and within that, some talented women in our engineering team.

It's certainly not lost on me that STEM careers are notoriously male-dominated, and for female developers, I know first-hand that some tech environments can be challenging and unfairly stacked against women, mainly through unconscious bias. It's not good enough, and it was important for me to ensure everyone is treated fairly, that diversity is championed, and that teams felt enriched by different opinions, experiences, and ways of thinking. After all, no company should exist in an echo chamber and expect to thrive. It is the amplification of the voices least heard that can lead to incredible things.

This week, I wanted to highlight the contributions of women that bring so much to our engineering focus, and continually lead by example with their truly awesome work. Read on to meet but a few of our tech superstars:

Julia Semeniuk, Scrum Master

What do you like about the software development process?
I like the results. I think its one very important part of the business: at the end of the day software development brings all ideas, feedback, and designs together and makes it available for other parts of the business and for our customers.

What challenges do you face in your role?
I think the biggest challenge is communication and alignment. We need to make sure we are working on the most important piece at any given time. Thats why working with Product, Support and other teams is so important to us.

What do you like most about your role?
I love spirit and teamwork. Every bit of work we do is accomplished because of synchronized work and collaboration. And to see the progression of our work and the growth of people makes me feel happy every day.

What initiatives do you take to support women in your team?
We are lucky to be treated equally in Secure Code Warrior. I dont think we have initiatives directed to women exclusively, we support and respect each other irrespective of sex and gender. In saying that, company initiatives such as parental leave and flexible working arrangements do make a huge difference to all of us.

Noemi Alvarez, Senior Software Developer

Role at Secure Code Warrior:
Senior Software Engineer

Favorite languages/frameworks:
Typescript /Javascript - Angular/Node because I have the most experience with these and I feel more comfortable.

Least favorite languages/frameworks:
Java / PHP because I didnt have the opportunity to work with these ones.

How did you get into software development?:
I did research on trending careers and IT was one of these and my favorite math teacher said I would be a great engineer.

What challenges do you face in your role?:
Keeping up to date with new technologies and trends.

What do you like most about your role?:
In general, to build/create something and see people using it. At SCW, to have the challenge to build it as secure as I can.

Laura Verheyde, Senior Software Engineer

Role at Secure Code Warrior:
Developer in the ACE team. Basically I help out with providing the platform with new challenges.

Favorite languages/frameworks:
C#, .NET.

Least favorite languages/frameworks:
Probably PHP, but thats mainly because of a lack of experience with it.

How did you get into software development?:
Years ago, my best friends were all studying IT, so that sparked my interest.

What challenges do you face in your role?:
Navigating and understanding someone elses code in order to add my own, can be a pretty demanding task. Also, the idea that there is still so much to learn in the area of IT can be intimidating at times, but also very rewarding once youve overcome a certain challenge.

What do you like most about your role?:
Part of my role has me delving through code on a syntactic level, something I find really interesting. Next to that, seeing the applications that Ive contributed to, producing results and creating new content for the SCW platform gives a very satisfactory feeling.

Do you have any advice for young women who are contemplating a similar career?:
Yes, dont be intimidated by the idea of having to work in a male-dominated workplace. My initial concern ebbed away pretty fast during my first days, as I was introduced to the nicest and most welcoming colleagues one could hope for. Im pretty sure thats the case in most workplaces.

Josh Graham, our VP of Technology, is developing a mentorship program to encourage more women into our engineering cohort. It's our goal to give them the opportunities and pathways to grow their career, while being guided by role models that can show them what is possible in software development, cybersecurity and tech. It is vital for young women to see someone they can relate to in an aspirational role, really hitting home that their dreams not only matter, but are within reach.

As an industry, and as a business, we still have work to do when it comes to achieving true equality for women in technology careers. We are working hard to encourage more women into our open roles; their contributions will only propel us forward and help us lead by example. The time is now to acknowledge biases, privilege, and glass ceilings, while making efforts to change the status quo in earnest.

We strive to create a safe, supportive environment for geeks of all backgrounds. We stand behind women in tech, offering work flexibility and generous parental/family policies in a global environment. Want to join us? Keep our Careers page and LinkedIn bookmarked for your next opportunity - we always have engineering roles for keen technologists looking to thrive in a workplace where you can come as you are.

A version of this article originally appeared in DevOps Digest. It has been updated and syndicated here.

At this point, I'm sure we're all getting a little tired of the phrase, "in these unprecedented times"... but, these really are unprecedented times. Who'd have thought at the end of last year, that we would be racing to defeat a globally destructive pandemic this year, and throwing everything we possibly could at it? It would have seemed almost laughable, and more along the lines of a new Netflix sci-fi series than part of our worldwide reality. COVID-19 has completely transformed our social lives, economy, and job security, not to mention political priorities.

One of the counter-attacks against COVID-19 has been through technology, with many countries rolling out contact tracing apps. Australia has COVIDSafe, modeled from Singapore's TraceTogether. Hong Kong, Taiwan, China, South Korea, Israel and Germany all have contact-tracing technology implemented, or on the way. The UK has been the hardest-hit region in Europe, with tens of thousands of virus-related deaths and a high infection rate. The release of their app is imminent. The USA -- also deeply affected with many people tragically losing their lives -- also has technology rolling out, but their state-by-state approach to contact tracing makes their situation quite complex.

With the exception of more state-controlled countries like China and Taiwan, the use of these apps is voluntary, requiring citizens to download and use the technology of their own accord. Some adoption rates are more successful than others; for example, Singapore's TraceTogether app had an adoption rate of 25%, rendering it quite ineffective for its desired purpose.

The idea behind contact tracing apps is sound. This technology, when functioning well, would ensure hotspots are quickly revealed and comprehensive testing can occur - both essential components of fighting the spread of a contagious virus. However, the words "government" and "tracing" don't exactly sound very inviting, and it's natural that people are cautious about what downloading something like this would actually mean for them.

So, what are the chief concerns of users? If online commentary is anything to go by, some of these misgivings include:

• Lack of trust in the government to use collected data responsibly
• Apprehension over how well personal data will be protected from cyberattacks
• Lack of clarity in what data is actually being collected, where it is stored, and with whom
• ... and for the developers/geeks among us, how solidly the apps are actually built.

It is always a bit of a worry when apps are built quickly, and these contact tracing apps are having to be rolled out in record time. It's a nightmare for developers, security people, and government agencies.

So, is mistrust a valid reaction? And what should we consider as a priority in our assessment of COVID-19 contact tracing apps and end-user safety? As a security guy, my instinct is, of course, to drill down into the cybersecurity elements of the program, namely how secure the codebase is for an app we're all (out of the best of intentions) being pushed to install.

Many of the apps are copies of each other (and inherit the same problems).

Australia's COVIDSafe app is essentially based on OpenTrace, as is Singapore's TraceTogether software. The problem, however, is that TraceTogether had a range of reported issues and a poor uptake, with just 25% of the population opting in as users - far short of the 75% required for it to be effective. There have been complaints regarding its general performance, especially on iOS, including batteries being drained very quickly. COVIDSafe has a potential UX flaw in its iOS version, requiring the phone to be unlocked and the app running in the foreground to record all data properly.

While the above issues are annoying, the more pressing concern is that Bluetooth vulnerabilities are rife and neither TraceTogether, nor Australia's COVIDSafe, are immune to them. On May 14th, NIST reported that COVIDSafe had a Denial of Service vulnerability, allowing an attacker to remotely crash the app if they are in Bluetooth handshake distance. This would allow an organized attack to disrupt contact tracing in densely populated areas, where it is most useful - something explained in detail by security researcher Richard Nelson. It is known to affect COVIDSafe, TraceTogether, Poland's ProteGO and Canada's ABTraceTogether - all inheriting the issue from OpenTrace's faulty manuData.subdata call.

There are other privacy and security issues relating to Bluetooth functionality in general, as well. The fact that this technology is being used to trace human movement through a unique ID (TempID) and collect meaningful data will inevitably mean a spiked interest in attackers testing for weaknesses, at which point exactly what is being collected, where it is being stored, and for how long, must be scrutinized.

Some apps are already showing signs of simple errors that cause complex weaknesses.

Australian software engineer Geoffrey Huntley has been studying the source code of COVIDSafe, and sadly, there are issues that are not necessarily being highlighted to us, the end-users.

One critical example was a privacy-breaching logic error that would allow an attacker to perform long-term tracking of devices; something that poses an enormous amount of risk for vulnerable users, not to mention it contravenes the Privacy Policy of the app itself.

It's important to note that these logic vulnerabilities have been patched as of May 14th, but the more pressing issue is that this was left unpatched, in the wild, for 17 days after Mr. Huntley reported it. He and other members of the awesome security community are tracking CVEs relating to the COVIDSafe app here.

One thing Huntley points out, post-patch, is that even the fix shows signs of, well, incompetence. In his public log, he notes the patch involved adding logic rather than simply deleting a flawed cache, with the latter being a far more robust remedy. Both work, but the live solution lacks finesse - a concern with such an important application.

Although we have diligent members of society using their own time and expertise to pore through source code and highlight issues, their job is made much harder than if the code was open source in the first place. As it stands, 28 apps are still closed off to security researchers.

Secure coding continues to trip us up at the finish line.

While I can certainly sympathize with overworked developers -- as well as the highly unusual situation of having to churn out a life-saving app in the midst of a pandemic -- the above should highlight that a few simple vulnerabilities in what is essentially a communal codebase could spell significant issues for millions of users.

I'd like to think most people want to be good citizens, support the app, and give everyone the best possible chance of contact tracing and controlling outbreaks of this horrific virus. I too am in support of technology that can help achieve this, but in many ways, this has unearthed the general lack of secure coding principles inherent in developers all over the world.

In any situation where software has to be written quickly, mistakes are not exactly unexpected. However, common security vulnerabilities like logic flaws, misconfigurations, and code injection errors should be something that can be prevented as code is written, not after volunteer white hats pick the codebase apart.

And it's not the developers'fault, by the way. They leave their tertiary education with little skills in secure coding, and in their careers, their KPIs almost always relate to feature functionality and speed of delivery - the security part is for someone else to deal with once they're done. We need to get to an end-state of secure coding at speed, and while now is not the time to make seismic culture shifts in the departments building these apps, it's a timely reminder that our digital risk area is expanding, and they are in pole position to make a difference if they're given the tools and knowledge to share the responsibility for security best practices.

Is it safe to download the app?

Here's the thing: for me, a security guy, I've come to the conclusion that the benefits of the app outweigh the issues. It's not ideal that the above vulnerabilities are - or have been - present in this software, but the implications of these being weaponized are worst-case scenarios. At the moment, contact tracing is a vital component of assisting our medical heroes all around the world in controlling the spread, stemming the flow of hospital admissions, and keeping each other as safe as possible.

It serves to highlight that we have a long way to go when it comes to enacting security best practices by default in a software build, and it's important the public does have the information needed to make informed decisions.

My family and I will continue to use it, though we remain vigilant with staying up-to-date with our Android patches, as we all should.

A version of this article ran in Cyber Defense Magazine. It has been updated for syndication here.

Cyberattacks have become a way of life these days. People almost expect to hear news about some new vulnerability or breach that affects everything from banking to aviation, or devices as diverse as smartphones and traffic lights. Even our homes are no longer completely safe. Entire cities and towns are being attacked by criminals almost daily with attackers demanding millions in ransom to restore compromised critical services.

But one place where we could hopefully still feel safe was at the doctor's office or even in a hospital. People are at their most vulnerable when reaching out to a healthcare provider. Human decency would almost demand that the local clinicians be allowed to do their noble jobs in peace. Unfortunately, that is not happening. There seems to be little honor  " or perhaps sheer desperation " among today's cyber-thieves. In fact, healthcare could be the next "great" cybersecurity battleground, with criminals attacking the very machines that diagnose medical problems, provide treatments and sustain life. With a sustained global health crisis unfolding before our eyes, this is something that is critical to address from multiple points.

Threats are getting more personal than ever before.

Attacks against the healthcare industry are not new. Cybercriminals already know the value that patient information, personal data, and financial records have in the underworld and on the dark web. That information can be used to steal money directly from patients, or as a launching point for secondary attacks such as phishing and other scams. It's no wonder then that many of the most devastating attacks lately have been aimed at healthcare. Anthem Healthcare had 80 million patient records stolen. Premera lost 11 million personal files. CareFirst's total was 1.1 million compromised records, and the list goes on and on.

As of right now, attacks made directly against medical devices seem rare. However, at least one report suggests that the problem might be much more widespread, with hospitals not reporting the intrusions, or employees untrained in cybersecurity simply not recognizing that an attack is taking place right in front of them. The ability to compromise medical devices in frightening ways, such as using malware to add fake tumors to CAT scans and MRI results, has been conclusively demonstrated by security researchers. It's not very much of a leap to think that attackers may already be doing the same or similar things to medical devices in the real world.

Healthcare is also uniquely vulnerable to cyberattacks thanks to its increasing reliance on devices within the Internet of Things (IoT), tiny sensors that are connected to the internet and which produce incredible volumes of information. For the most part, securing the information produced by those sensors, the channels they use to communicate, and even the sensors themselves, has been little more than an afterthought. The number of potential vulnerabilities that an attacker could exploit hiding within those IoT-dominated networks is likely almost limitless.

IoT in healthcare poses serious risks.

Services critical to patient care " which in some cases weren't even imagined 20 years ago " are breeding grounds for both IoT-based and other more traditional vulnerabilities. Electronic medical records, telemedicine, and mobile health were all seemingly waiting for the boost of information that IoT could provide. It's no wonder that the commitment to IoT in the healthcare sector is staggering. MarketResearch.com predicts that by next year, the IoT market in the healthcare sector will reach $117 billion, and continue expanding at a rate of 15% every year after that.

In that environment, skilled attackers can find plenty of vulnerabilities that can be used to exploit medical devices. IoT sensors embedded inside medical devices generally communicate and produce their data in one of two ways. Some gather data and then transmit all of their findings directly to the internet for analysis. Others use a form of distributed networking known as fog computing where the sensors themselves form a sort of mini-network, collectively deciding what data to share with a central repository or platform. That data can then be further processed or directly accessed by healthcare workers.

Further complicating cybersecurity matters within healthcare is the fact that the industry has never embraced. nor agreed upon, data handling standards, methods or protections. Historically the healthcare industry has been served by manufacturers that offered their own proprietary technologies for medical devices. Today this includes the embedded IoT sensors, the communication channels the devices use and the platform for analyzing the data after it's collected. This makes most hospital networks a hacker's dream, or at least a fine proving ground where they can exploit everything from security misconfigurations to insufficient transport layer protection. They can try anything from cross-site request forgeries to the classic XML injection attacks.

The counter-punch we need is right in front of us.

Despite the potentially catastrophic consequences of these vulnerabilities being exploited, there is something to remain optimistic about: these security bugs are not new, powerful back doors opened by criminal masterminds. They're so common that it is frustrating to keep seeing them, time and time again. Part of the reason they rear their ugly head is through the use of legacy systems that have gone unpatched despite fixes being available, but the other is once again related to the human factor. Developers are writing code at a cracking pace, and they're concentrating on a slick, functional final product... not security best practice.

There is simply too much software being built for AppSec specialists to be able to keep up, and we can't expect them to constantly save the day with these recurrent vulnerabilities. It is cheaper, more efficient and clearly much safer if these vulnerabilities are not introduced in the first place, and that means security teams and developers must go the extra mile to create a robust, end-to-end security culture.

What does a great security culture look like, exactly? Here are a few key elements:

• Developers are equipped with the tools and training they need to squash common bugs (and understand why it's so important to do so)
• Training is comprehensive, easily digested and plays to developer strengths
• The outcomes of the training are properly measured, with metrics and reporting (not just a tick-the-box and move on exercise)
• AppSec and developers start speaking the same language: after all, in a positive security culture, they're working to achieve similar goals.

The possibility for disaster is still enormous, and goes well beyond just having a patient's medical records stolen. Injecting fake tumors into a scan could devastate a person anxiously waiting to hear if they have cancer. And changing out medicines or altering treatment plans could actually kill them. But, it only takes one cybercriminal willing to cross that line for profit, and you can guarantee that it will happen. Perhaps the next ransomware scam won't encrypt a hospital's data, but instead, ruin the diagnoses for thousands of patients. Or perhaps an attacker will threaten to alter medicines unless they get paid, literally holding lives for ransom.

It's clear that we can no longer follow the "business as usual" approach when it comes to cybersecurity in healthcare. We can't rely on one or two specialists at healthcare organizations to fix every problem. Instead, we need security-aware developers working on healthcare apps and devices to recognize potential problems and fix them before they are deployed at facilities. And even healthcare workers could use basic cybersecurity training.

It's true that nothing is more important than your health. Within the healthcare industry, maintaining good cybersecurity fitness for the future will depend on facilitating better overall security awareness today. Without serious treatment, this is an issue that is only going to get worse.

A version of this article originally appeared in Dark Reading. It has been updated for syndication here.

In our industry, many security experts have made a habit of predicting the hot-button issues for the coming year (and I am no exception), but with more than five billion sensitive data records stolen in 2019, I figured it would be more accurate to predict what won't be happening in cybersecurity in 2020, or indeed the foreseeable future.

I sat down with my co-founder, Matias Madou, and we had a few laughs putting together this list. It's intended to be somewhat of a lighthearted outlook, but it does make you reflect on the long road ahead to fortify every organization against malicious cyberattacks.

Now, lets look into our crystal ball and reveal our predictions. We won't be seeing:

SQL injections eradicated from all software

I think every security professional on the planet has been waiting for the day where they are no longer derailed to identify SQL injection bugs, ad nauseam.

Sadly, we've been waiting for this day for more than twenty years, and we'll keep waiting for at least one more. It's the vulnerability that, like a cockroach, has survived every tactic thus far to eradicate it for good.

It's frustrating to say the least, since the remedy has been known for pretty much the same length of time. However, the prioritization of security best practice at every stage of software development (especially right from the beginning) remains too low, and certainly inadequate in light of the vast increase of code production since the discovery of SQL injection.

(Want to understand more about the coding patterns that could lead to SQL injection? Take the challenge here).

Developers and AppSec becoming best friends

Ah, developers and the AppSec team. Will they ever get along, or are they destined to a life of rivalry like Rocky vs. Apollo? The short answer is yes, they can get along, but right now their priorities are often very different.

When they meet in a project environment, they're on opposite pages and clash right at the final hurdle: when AppSec specialists are poring through a developer's code. The developer has built beautiful, functional features (which is their top priority) that are torn apart if security vulnerabilities are discovered. The software security guru has, in effect, called their baby ugly and forced the developer to go back and fix any bugs, often delaying deployment.

In our current state, this won't be fixed until developers and AppSec teams work towards a common goal, which is the creation of secure software. It's not going to happen as a default process in 2020 (and with many companies, quite a few years after that), but with the advent of the DevSecOps movement and beyond, developers are recognizing the need to upskill in security and work to a higher standard; one that includes security objectives from the beginning.

An oversupply of security professionals

In 2020, 2025, 2030... it's almost guaranteed that we will be short-staffed globally when it comes to security expertise.

According to a report from ISC(2), there are around 2.93 million cybersecurity positions currently unfilled. This is almost certainly going to get worse before it gets better, and there is no hidden security army waiting to march to our rescue in the next few years.

In the immediate future, our best chance to address this skills shortage is to make security an organizational priority and upskill our existing workforce, and that means empowering developers with the training and tools to code securely, as well as creating a company-wide security culture. Most current AppSec teams are probably fighting against well-known, old security bugs (see point 1 above). If we ensure they don't have to spend precious time and effort fixing these common issues, they will have more bandwidth to focus on tough security problems (at the moment, these are likely to encompass issues with APIs, as well as building tools that can fit development pipelines).

Less code being produced

The world is being digitized at a staggering rate, and societal demand is not going to waver. There are approximately 111 billion lines of code written each year, and this number will only grow larger and more terrifying (for the already-stretched AppSec teams, anyway).

Increased code volume inevitably increases potential security vulnerabilities, so any thinking around 2020 being a slower year for software production and breaches are about as realistic as unicorn racing being held at the Grand National.

A reduction in data records being stolen

As I said, more code means more vulnerabilities, and this presents more opportunities for attackers to find a way to steal data.

At least 5.3 billion records were stolen worldwide in 2019, and defense against attackers is still a bit of a desperate, reactive scramble. This number may not double in the next twelve months, but I think it will get close.

As an example, let's look at the historical trends of reported stolen data in the United States year-on-year:

Looking at the period between 2005-2010, there is a steady rise with a little ebb and flow between years. This is interesting, but an important factor to highlight is that in 2009, there was a sharp decline in the number of reported breaches as compared to 2008. However, there was a distinct increase in the number of records stolen despite fewer breaches.

Data records are the new gold; they have value to an attacker. The chart reflects a general upward trend in breaches and number of stolen records, with a huge peak in 2017. The number of attacks trended downwards in 2018, perhaps due to tougher security measures, but the number of records obtained was the highest it has ever been. Cyberattacks will become increasingly sophisticated, high-volume and are not going away any time soon. And globally, we are unlikely to see a downturn in 2020 as companies rapidly produce more software than ever before. They are the gatekeepers of our data and need to work smarter to protect our privacy.

Developers demanding longer, more frequent video-based security training

If there is one thing developers love, it's watching hours upon hours of computer-based training (CBT) videos. In fact, such is the demand for this captivating content, Netflix will announce a whole new sub-category dedicated to generic security training videos.

Er, nope. Not now, not in 2020, not ever.

For developers, their introduction to security is often by way of workplace compliance training. Secure coding is rarely part of their tertiary education, and on-the-job training can be the very first encounter with software security. And, unsurprisingly, they often don't like it.

For developers to take security seriously - and for training to be useful - it has to be relevant, engaging and contextual to their jobs. One-off compliance training - or an endless stream of dull videos - is not the way to a developer's heart, and it's not going to reduce vulnerabilities.

If you want the developer cohort to have any chance of becoming a security-aware defensive force against common vulnerabilities, get them working with real code examples - the kind they would come across in their day-to-day tasks. Make the learning bite-sized, easy to build upon, and incentivize it with a sense of fun. For a security culture to thrive, it must be positive, engaging and develop real skills and solutions across the organization.

Who knows? With the right training, a developer might recognize their inner security champion and spread the benefits of secure coding far and wide.

Zero deaths from a cybersecurity-related incident

Okay, so this is clearly no laughing matter. I've said many times that the world simply won't care about cybersecurity until people start dying from a cyberattack-related incident.

The problem is that this has already happened, and it went largely unnoticed.

Cyberattacks against US hospitals have been linked to a rise in heart attack deaths in 2019. Of course, the attackers did not cause lethal cardiac events in patients, but their ransomware attacks on hospital systems and equipment slowed treatment times for critical care.

This study from the University of Central Florida analyzed 3000 hospitals, 311 of which had experienced a data breach. In those that were affected by a security incident, they took an average of 2.7 minutes longer to give suspected heart attack victims an ECG; likely due to procedural changes, newly implemented security measures and IT support issues taking up more time than it did previously. Identifying and treating a heart attack is a race against time, and those hospitals saw an additional 36 deaths per 10,000 heart attacks per year on average.

This is shocking, and unfortunately, I think it will get worse before it gets better. This should serve as a stark reminder that we all need to do more to uplift software security and make it front-of-mind in every business.

Fewer stock images of "hooded hackers"

If you type "hacker" into an image search, you will inevitably uncover thousands of images of a hooded, faceless figure typing away at a laptop, or a similar figure in a Guy Fawkes mask.

This stereotyped image of a hacker is getting really tired, and, well, makes everyone look like a bad guy. There are plenty of security good guys and girls, and the negative connotations around the "hacker" image do everyone a disservice.
Do I see this changing any time soon? Probably not, but it's nice to dream. For now, it's important to remember that security doesn't have to be scary.

In a digitally driven world, we are at an ever-increasing risk of data theft. With large organizations acting as the gatekeepers of our precious information, many are recognizing the need to implement stringent security standards.

Much of the initiative around "shifting left", that is, introducing security much earlier in the development process, simply doesnt move the needle far enough. There is an implication there that we are still beginning the process the wrong way, ultimately backpedaling to achieve the outcome of more secure software. We must start left, enacting a cultural shift that positively engages development teams and arms them with the knowledge they currently lack. However, all training and tools are not equal.

In this article, we explore the ways that key leaders like security awareness and development managers can truly empower their developer cohort, transforming them into the defensive front-line against costly cyber attacks.

Shift left vs. start left: An important distinction.

In the age of frequent data breaches affecting some of the world's most trusted organizations, company leaders have looked to the security industry to provide guidance on avoiding the financial, reputational and showstopping disaster that is a successful attack.

For quite a while, AppSec specialists (including myself) have advised that we must indeed "shift left". In-keeping with DevOps best practice, as well as better software security outcomes, many of us advised that the security part of a software build must come sooner in the software development lifecycle (SDLC). It should not be the final, costly step - rather, it should shift closer to the start of the process, with AppSec teams engaged early as software projects come to life.

This is not bad advice, and it's certainly better than the old way of doing things (which, if the amount of stolen data out there and age of the vulnerabilities used to heist it is any indication, isn't working anyway). However, if we actually started left, the security outcomes would be far more positive.

Shift left, start left... what's the difference? The difference lies in how you engage your development team. Truly, they are the key to delivering more secure software, much cheaper than later-cycle toolchains and manual code review can manage. In an ideal world, every single developer writing software would have the knowledge and tools to code securely from the very beginning. They would spot potential flaws, mitigating them before they're committed (and thus far more expensive to weed out and fix). There would be a dramatic reduction in the security bugs we've seen for decades - ones that are still responsible for allowing attackers in through the back door. Those windows of opportunity in the form of SQL injection, cross-site scripting and broken authentication would close.

However, right now, there simply isn't enough emphasis on security at the vocational level, and on-the-job secure coding training varies wildly. As a result, developers rarely have what they need to enable an organization to start left. Its time for those in leadership positions to work together and advocate for broader security awareness, with their direct knowledge and contact with developers vital in driving programs that work. After all, development managers were once sitting in their position, on the tools and with the security space difficult to navigate at the best of times.

Developers don't love security (yet)... but you can change the conversation.

You know how it goes: mention "security" to your typical developer, and you're likely to be met with an eye-roll at best, or puzzlement at worst. Generally, the whole security thing is seen as someone else's problem.

A developer has a primary responsibility of building software that is functional, brimming with innovative features and delivered within a tight project timeline. Security is rarely a priority at the coding level, and can even be seen as a tedious blocker to rapid delivery and getting creative. AppSec has the task of meticulously checking code, pen-testing and then reporting the bad news: the presence of security vulnerabilities in code that is often already committed, and functioning quite fine otherwise. It's an expensive process in an environment that is often stretched for resources and time, with the setup bound to cause a rift between two teams that have ultimately the same goal, but speak completely different languages.

Now, in this climate, the reception to mandatory security training is likely to be quite chilly. But, the power to ignite a security mindset in every developer isn't a pipe dream. With the right kind of training and support, they can start to bake security into their software and take responsibility for the security outcomes they are able to control. If developers themselves can take care of the common bugs, that frees up the expensive specialists to iron out the truly complex problems. And if youre in the position of managing a development team, you can be instrumental in helping to bridge this gap and help your team see the benefits.

All training is not equal.

When was the last time you got really excited about learning something new? In the times you did, words like "mandatory", "compliance" or "seventeen hours of video" probably wont come to mind.

Developers are no different. They are clever, creative and love to solve problems. It is quite unlikely that watching endless videos on security vulnerabilities is going to engage them, keep the content memorable or end up specific to their everyday roles and responsibilities. In my time as a SANS instructor, it became apparent very early that the best training is hands-on, forcing participants to analyze and be challenged intellectually, using real-world examples that test their brain and build on prior learning. Gamification and friendly competition are also powerful tools to get everyone on-board with new concepts, while remaining useful and practical in application.

Another scary factor is that a lot of security training goes unmonitored. Nobody likes to feel as though Big Brother is watching, but what is the point of spending time, money and effort on education if no-one is checking whether it is relevant?

The right solution can make secure coding fun, relevant, engaging and measurable. Challenge your developers, treat them well and make it a special event. Gamified training lights up the reward centers in the brain, and offering an incentive to keep learning, push knowledge boundaries and, quite simply, build a higher standard of software, is a win-win.

Security culture health check: Is yours on life support?

Creating secure software in an environment with a poor security culture is like trying to win a marathon with a boulder chained to your ankle: virtually impossible, and unnecessarily difficult.

Gamified training, head-to-head tournaments and a commitment to assisting developers in their security growth help immensely in driving a positive security culture, with AppSec and development teams gaining much more insight into each other's day-to-day work. Better relationships grow and thrive, and the (often limited) security budget isn't burned through on fixing a "Groundhog Day'scenario of the same small, annoying bugs time and time again.

There's another powerful byproduct, too: the unearthing of the security champions you never knew you had. Proper training that gets everyone involved, while also allowing for a thorough assessment, can uncover those that not only have an aptitude for security, but actively display a passion for it. These champions are vital in keeping the momentum going and acting as a point of contact between teams, overseeing peers and upholding best practice policies. Implementing a solid champion program, one that includes recognition and executive support, is a feather in the cap of the organization, as well as looking mighty impressive on the individual's CV and bolstering their future career.

When you commit to a positive security culture, responsibility is shared and a greater tier of secure software excellence can be achieved. Ultimately, every person in the software development lifecycle must adhere to a simple mantra: if it's not secure software, it's not good software.

Spread the word.