If I asked you how much it would cost to change just one line of computer code in a device that's already in service, what number would come to mind? A few hundred dollars? Maybe thousands?

According to Aviation Today, it costs $1 million for a commercial airline to update a line of code in its planes. For a cost so substantial, they would likely need a compelling reason to take the steps required to make any update to their airplane's systems, which really got me thinking about a number of factors.

Breaking down the cost

While the article doesn't outline what comprises the $1 million cost, I think it's a viable figure. I'm not an expert specifically in airline software updates, but I can assume a few of the steps the airline is forced to take in this situation.

First, the airline needs to discover a flaw or vulnerability that necessitates the update. The cited example consists of research performed by the U.S. Department of Homeland Security (DHS)  on a Boeing 757. The results - a remote hack after only two days of work - are more than compelling enough for any airline to take note.

From there, software developers need to analyze the findings, write new code, and test it in a safe environment to ensure the issue is fixed. Now comes the tricky part. The airline needs to ground each vulnerable or flawed aircraft, apply the new code, test it to ensure it works with that specific plane, and then recertify that plan for commercial flight.

According to airfleets.net, Southwest Airlines currently has 499 Boeing 737-700 planes in its fleet. Consider the time and money investment involved if a security flaw emerged in this particular plane model.

Not just an airline challenge

Clearly, airlines should have a vested interest in employing sound secure coding principles from the start. After giving it a few moments'thought, I could see numerous industries and situations where a similar cost might apply. Instead of worrying about airplanes falling out of the sky due to a hacked vulnerability, what about medical devices like pacemakers? How much does it cost to recall and update a half-million lifesaving pieces of electronics?

In the automotive industry, we continue to hear talk and security concerns about self-driving cars. Yet, even our "typical'vehicles rely more heavily than ever on connectivity to the internet, which leads directly to some troubling - if entertaining - safety concerns.

It's a simple fact that it costs much more money and takes more effort and time to update devices or systems after they've been released into a production environment, or before they've been mass produced, than it does to build security into your initial development process. Yet, we still continue to see new preventable software flaws and cybersecurity vulnerabilities every day, underscoring the need for companies to look for ways to build secure software development into their development culture.

The cost to change one line of code on a piece of avionics equipment is $1 million, and it takes a year to implement. For Southwest Airlines, whose fleet is based on Boeing's 737, it would "bankrupt" them if a cyber vulnerability was specific to systems on board 737s

‍

The focus of most cybersecurity discussions relate to protecting money, reputation and information. Within financial institutions, it is often a threat to personal or company finances. In the telecommunications industry, it is more about personal identity information or intellectual property theft. At a government level, cyber-espionage is a relatively easy and low-cost way to acquire high-value intelligence.

However, the dangers of cyberattacks on physical infrastructure including SCADA (Supervisory Control and Data Acquisition) and ICS (Industrial Control Systems) are very real, growing and frightening, as a recent New York Times article about an attack on a petrochemical company with a plant in Saudi Arabia explains.

Within the Oil and Gas sector, cybersecurity attacks can cause explosions. For a long time, these plants were not connected to networks, but now, in the interests of simplicity of management, they have all been dangerously connected. The probability of these systems being attacked - and successfully so - is now much higher. These  applications are NOT designed with security in mind, because, it was not the intention to have them connected to the internet.

The NYT article details an attack that was not designed to simply destroy data, or shut down the plant, but also to sabotage the firm's operations and trigger an explosion that would likely harm other humans. Investigators said the only thing that prevented an explosion was "a mistake in the attackers'computer code", one which they believe the hackers have "probably fixed by now". Investigators believe it is "only a matter of time" before they deploy the same technique against another company successfully.

Software developers are becoming key architects who underpin the success and safety of many public and private organizations. There is no greater example than in the Oil and Gas industry. It is more important than ever that they have a better knowledge of the security implications of their work and that they learn how to code securely, whatever language or frameworks they use.

If you want to see how developers can learn about security to help protect critical infrastructure, play the following challenge:

https://portal.securecodewarrior.com/#/simple-flow/web/injection/oscmd/cpp/vanilla

The only thing that prevented an explosion was a mistake in the attackers'computer code, the investigators said.

https://www.nytimes.com/2018/03/15/technology/saudi-arabia-hacks-cyberattacks.html

The cyberassault was not designed to simply destroy data or shut down the plant, investigators believe. It was meant to trigger an explosion. https://t.co/kQqcAhoW01

" The New York Times (@nytimes) March 15, 2018

A Cyberattack in Saudi Arabia Had a Deadly Goal. Experts Fear Another Try. https://t.co/q9UdicR7dv

" Colin Wright (@colinismyname) March 22, 2018

The attack was a dangerous escalation in international hacking, as faceless enemies demonstrated both the drive and the ability to inflict serious physical damage. https://t.co/G8bBCteouZ#CyberSecurity #NetworkMonitoring

" Elitery Indonesia (@eliterydc) March 22, 2018

A recent failed #cyberassault on a Saudi Arabian petrochemical company had a deadly goal. This @NYTimes article explains more: https://t.co/3g8oDuPijm pic.twitter.com/MfSqrXSd9u

" Symantec EMEA (@SymantecEMEA) March 21, 2018

On a recent long-haul flight, I took the opportunity to devour a, quite frankly, insane volume of podcast episodes. Keeping up-to-date with so many different series means I am never short of something to listen to, with compelling -- albeit one-sided -- conversation just a touch of my phone screen away.

Eventually, I got to an episode of the true crime podcast, Casefile. This dramatic, no-holds-barred series (complete with an ominously-voiced and nameless host) delved into a topic that fascinates even the most knowledgeable and savvy technologists: the deep web, and the cataclysmic ascension of contraband trade website, Silk Road. Split into two parts, those familiar with the rise and fall of Silk Road would have undoubtedly followed news on the case, but the podcast divulges every little detail, in delicious, edge-of-seat narrative.

The Silk Road: Lessons From The Deep Web Dungeon

If you're not intimate with the ins-and-outs of Silk Road, the TL;DR summary is that a man built a trade website on the deep web, hidden from the prying eyes of the general public and unviewable without the use of special software - the Tor browser, to be exact. The site initially only offered his homegrown magic mushrooms, but, virtually overnight, exploded with vendors offering everything from hardcore drugs to illegal weapons and stolen credit card details. You can get up to speed here. The creator and site admin went by the Princess Bride-inspired pseudonym, Dread Pirate Roberts. He was everyone, he was no-one. All users traded a veritable bounty of illegal goods, and they did it completely anonymously (and in the process, got Bitcoin a reputation as the drug dealer currency of choice; a moniker it is only just beginning to shake).

However, Dread Pirate Roberts'anti-establishment experiment was a beast unto its own. Soon, hitmen were advertising their services. Bad people were doing bad things... and he was intoxicated by his newfound unfathomable wealth. He even tried to utilize the services of an advertised hitman to dispose of a former employee. Long story short, this was one of many knuckle-headed decisions that brought about his undoing. He has been unmasked as Ross Ulbricht and he is currently rotting in a US jail cell, serving a double life sentence plus forty years without the possibility of parole.

But, how was he caught if everything was completely private and anonymous?

Well, to put it bluntly: he was a pretty crappy coder. The Silk Road site itself was like a leaky old barge marooned in the ocean. Considering it was a hub of illegal activity (and all the data behind that activity) it was not secure at all; it was a sitting duck just waiting to be exploited by an opportunistic hacker. To be fair, when you're the mastermind of a huge, illegal drug trafficking business, it's probably not easy to find competent employees who would like to get involved with your operation. He made no secret of his skill-gap, either - he even posted under his real name on Stack Overflow (yep, that's his user account), asking for help to properly configure his site code to connect with Tor using Curl in PHP. He changed his real name to the handle "frosty" less than a minute after posting, but this clearly didn't help... in fact, it probably did further damage: the encryption key on the Silk Road server ended with the substring "frosty@frosty", thus implicating him further once the FBI caught wind of his scent.

Despite such a huge push for privacy, with encrypted messaging, currency and explicit instructions on securing the contraband itself in transit and delivery, the site was not the impenetrable fortress of libertarian fantasia that Ulbricht may have envisioned. Those with the skills (read: programmers employed by the FBI) slowly, but surely, unraveled it to reveal everything... including the identities of thousands of people who transacted on the site. It's possible that those who purchased naughty goods many years ago are still going to get a knock on the door from long arm of the law at some point, like this guy in Germany. Yikes.

The FBI released documentation outlining how they were able to penetrate Silk Road, with the general explanation being that of utilizing an IP address leak. A misconfiguration of the Silk Road login page revealed the IP address and thus the physical location of its servers, without any underhanded hacking required. A rookie error, to be sure, and one which eventually led the FBI straight to Ross Ulbricht.

There is speculation that this flaw - if it did exist - would have been spotted long before this moment in time, by one of the many security professionals monitoring the site. Nik Cubrilovic, an Australian security consultant, claims it simply wasn't there in an interview with WIRED:

"There's no way you can be connected to a Tor site and see the address of a server that's not a Tor node. The way they're trying to make a jury or a judge believe it happened just doesn't make sense technically."

Cubrilovic then goes on to allude that the information may have been obtained by illegal hacking practices. That practice seems to be SQL injection, an unproven rumor that has been discussed as a plausible method of extraction on many sites since.

The legalities surrounding the tactics of the FBI are an entirely separate discussion. The fact the information could be obtained at all is indicative of Silk Road's poor security practices, despite the general user understanding of the site being "private". When privacy is confused with security, the possibility of exposure to vulnerabilities is most certainly increased.

There is also the possibility that the site would still be running (in its original form, anyway; it has been resurrected several times, and there are even larger sites just like it operating right now) if Ross Ulbricht had made the distinction between privacy and security, actively working to ensure both before it grew into a giant heat lamp, attracting every unsavory crook with slightly above-average tech knowledge on the planet. Instead, the private club and all its secrets were revealed the moment someone found a way to open the door.

You're not a drug lord, so why should you care?

The loss of Silk Road and imprisonment of its founder is not a sad, sympathetic tale, but it is a fascinating case study into the nuanced differences between privacy and true, robust site security. There are many legitimate operations that require transactions and information to be private - think digitized medical records, or even the millions of credit card numbers held by a large bank - but if they are not also secured with iron-clad software development, that information could be cherry-picked by an attacker (and, ironically, end up on a site like Silk Road). Privacy does not exist without security.

The good guys, like you, could have software that is vulnerable to SQL injection attacks and other vulnerabilities from the OWASP Top 10, so it is vital that these are prepared for and mitigated efficiently. If developers are trained to code securely from the very start of the process, these flaws won't see the light of day. It is imperative that organizations are focused with a security mindset, and empowering their dev teams to code securely. We can show you how to do it the fun, measurable and gamified way. Are you ready?

Around the globe, companies are transforming. With a heavy focus on digital-first business, it is fair to say that most organizations are, in fact, software companies. Large enterprises count huge development teams among their staff, tasked with constant feature development and deployment in an agile DevOps environment. This feature delivery must keep up with the pace of innovation and customer expectations, so all too often, security is seen as a roadblock rather than a necessity. However, with our reliance on software at an all-time high (and subsequently our exposure to potential cybersecurity breaches and risks), this scenario cannot continue.

Security teams are not getting any bigger, and even if they could, the expertise is in short supply. Ratios of 1:100+ are simply not enough; proprietary security experts cannot be seen as the only solution to countering the cyber threat problem.

Our webinar, presented by Secure Code Warrior's Director (Americas) Stephen Allor and Russ Wolfe, Dean of Cybersecurity at Capital One, goes in-depth on the current issues facing DevOps, and what financial institutions like Capital One are doing to engage and upskill their development teams on secure coding, effectively fostering a positive security culture and successfully "shifting left'.

You will discover:

• If you are a victim of the security knowledge "black hole'
• Why security was more robust decades ago, versus now
• The traditional attitude towards AppSec as the compliance "checkbox", and why this is superficial at best
• The reason why quality assessments for applications must include security as part of the benchmark; an insecure application cannot be considered high-quality, no matter its design or features
• Why the industry has not built software security into the mindset and culture of the average developer (and why this must change)
• How the lack of shared secure coding skill keeps the same vulnerabilities appearing time and time again
• Why application scanning tools will not find every vulnerability, and why avoiding them by utilizing sufficiently trained secure engineers/developers is a more viable tactic
• The issue of growing vulnerabilities in software and their root cause
• Why the approach, not the student, needs to change in order for real risk mitigation to occur
• Why most security education does not play to developer strengths, and the kind of training they do need to excel
• The reasons software engineering compliance and build expectations fall behind other branches of engineering, and how we are pioneering the solution to that
• How Russ Wolfe and his team at Capital One has designed a certification program around fun, gamified training that keeps developers engaged, learning with real-world source code and achieving benchmarks in security best practice
• How this certification program fosters participation, information retention and continued learning
• How incentives help developers move through training tiers, upskilling quickly and in-line with key security policy
• How assessments help identify security champions and drive training engagement.

Watch our webinar now, on-demand, and discover the benefits of shifting left and empowering developers with the tools and knowledge to code securely from the start, with a focus on positive security practices.

Discover what financial institutions like Capital One are doing to engage and upskill their development teams on secure coding, effectively fostering a positive security culture and successfully "shifting left'

Perhaps we're speaking with a teensy bit of bias, but here at Secure Code Warrior, we think a career in software development and engineering is an exciting, rewarding path for any individual to follow (and it's getting bigger every day!).

June 23 is International Women in Engineering Day. In celebration, we sat down with Lucy T*, a senior developer for one of the Asia-Pacific region's largest telecommunications companies, to learn more about her experience, career and future plans. An enthusiastic, whip-smart individual, Lucy's expertise spans more than a decade - across several languages, platforms and projects. Her workspace is a reflection of her technological prowess, with a self-built high-end gaming rig and 3D printer the centrepiece of her engine room.

When asked to reflect on her software development beginnings, she cracks a wry smile, "I fell into it by accident. I started out in design at uni and then discovered it wasnt anything like what I thought it was going to be, so I dropped out of that. I struggled to think of something that I would like enough to do as a career, and figured well, Ive always enjoyed computers, my father works with computers. Ill do a computer science degree and see how I go. I discovered that yeah, I actually do quite enjoy that. I thought I would end up in an infrastructure or service support sort of career, and then got a development opportunity in a graduate program. Turns out that's exactly where I needed to be." As a rule, Lucy isn't big on luck. Highly logical and a meticulous planner, she mulls over this happy accident well aware of the irony.

More than ten years on, her day-to-day duties mainly revolve around specialised project work, supporting large systems with new feature implementation and fixing of defects. With thousands of users navigating her platforms on any given day, she's often on-call for rapid patch deployment and guiding colleagues on viable solutions: "When weve got a large project involving the introduction of a whole new set of functionality into the system, that's where things can get tricky. It's paramount to keep the existing service running, but general support like explaining to users how to perform a new function also factors in."

Her tenure and skill-set often require her to jump between platforms and languages, keeping multiple projects well-supported. Her background includes six years of .NET development in C#, but she has since expanded to JavaScript, Java and several platform-specific APIs. When asked to play favourites, she sighs deeply, resting her chin in her hand. "What I appreciate most is flexibility. That's what stands out about JavaScript now that Im using it from day-to-day. I will say, though, that I absolutely hate Java, which is funny because people tell me that C# is like Java... it's not, at all. Java pretty much sucks." She erupts into laughter, scaring her giant fluffy cat off the couch. Her bluntness is refreshing.

Lucy's seniority in the team can also mean that she is the one championing the security aspect of her job, especially to recent graduates or junior developers being welcomed to the fold: "In my field, security is obviously a huge priority. No one wants a very expensive fine from exposing data. The organisations very aware of sensitive information, personally identifiable information, all that kind of thing. In my current IT team, its important that the things we develop are properly locked down from a security perspective. Only the right people should be looking at this data, accessing this data, and not have inappropriate permission such as editing versus just reading. I make it a priority to emphasize this with anyone new coming on the team."

We took Lucy through the Secure Code Warrior platform demo, something she conquered with impressive ease: "I like how this is very specific to the programming language. I find that most security courses that Ive undertaken in the past are very much an organizational level, "Oh, be careful of what kind of data youre exposing,'as opposed to actually looking at, "Well what am I doing for my day-to-day life, and what can I actually do from that perspective?'This looks like a great way to start from a beginner level up to more experienced coders, in what they can actually do just in their day-to-day working life to make things safer."

Our conversation turns to International Women in Engineering Day, and we ask her to ponder the challenges, if any, she has faced as a woman in such a male-dominated space. She is clearly in her element when it comes to software development - as well as highly skilled - but finds that certain tasks still default to her: "I think the main challenge is not so much that guys assume you're not tech-inclined - that's never been a problem for me. It's more the assumption that as a woman, you will also be good at communication or that you will lean towards those kinds of communication-based skill-sets. Soft skills, documentation, all that kind of stuff. I have definitely found at times that I have been stuck with documentation work or with managing a customer relationship when that wasnt part of my job description, just because my manager assumed that Id be better at it as a woman." Her infectious laughter boils over again. "I dont enjoy interacting with people as much as everyone assumes I do!"

In our research, we discovered that many female developers lack a support network in their career, especially from female mentors. For Lucy, she feels - at least currently - that she is supported by managers and colleagues to thrive: "I think Im in a supportive team at the moment. Ive got supportive managers, Ive got mentors. If Im stuck on something, I have people that I can talk to for either immediate project help, or even career-based help such as where I can head in the future. Where someone in my position could aspire to be in a few years time, career goals, that kind of thing."

Would she have had the same answer earlier in her career? "I definitely wouldn't say this was indicative of my experience, say, seven years ago. Upon reflection, it was kind of lonely at times."

For women staring down the path of a career in software development, Lucy is passionate about encouraging them. When asked if she had any particular advice, she sat forward in her chair, a picture of seriousness: "Put simply, do not underestimate yourself. Seek out other people in your position, and other women in the same career if you can. Just to get to know other people in a similar environment, to know that youre not alone and that the things that youre experiencing are pretty normal. That way, you might learn to value your own skills sooner, and realize that maybe those people that are saying, "Yeah, Im excellent at this,'are actually at the same level as you. Theyre just better at saying they can do it, or are willing to say, "Yes, you should give me a shot at this.'If you work hard, keep up to date, I guarantee you're just as good as them. Take it and run with it."

Initiatives like Code First: Girls, who are committed to helping 20,000 women learn to code by 2020, are helping to raise the profile of software development as a viable career for women, opening opportunities that would have perhaps gone otherwise unconsidered.

Secure Code Warrior co-founder and CTO, Matias Madou is also passionate about supporting the growth of women in the industry: "As a tech startup, it's not easy to attract a diverse pool of talent willing to put in hard work and lots of hours to follow our mission to empower developers. Over the last six months, we have hired eight incredible women in both management and business positions. Our engineering team has about nine different nationalities and I strongly believe that diversity leads to creativity and more empathy. We are committed to ensuring our team is a place where women can thrive."

(And hey, while we've got you: if you're a developer looking for a new opportunity, we're always seeking out talented coding warriors to join Team Awesome! Check out our Careers page.)

* Lucy T is a pseudonym to protect her identity as a secure development professional in a large corporation. She agreed to this interview on the condition of anonymity.

I thought I would end up in an infrastructure or service support sort of career, and then got a development opportunity in a graduate program. Turns out that's exactly where I needed to be.

Depending on the application, the process of serialization can happen all the time. It's the term used to describe whenever data structures or object states are translated into a format that can be stored or possibly sent as a communication. Deserialization is the opposite of this process, taking the now structured data and turning it back into the object or data string that it was before storage.

Insecure deserialization can happen whenever an application treats data being deserialized as trusted. If a user is able to modify the newly reconstructed data, they can perform all kinds of malicious activities such as code injections, denial of service attacks or simply changing the data to give themselves some advantage within the application like lowering the price of an object or elevating their privileges.

In this episode we will learn:

• How attackers can exploit insecure deserialization
• Why insecure deserialization is dangerous
• Techniques that can fix this vulnerability.

How do Attackers Exploit Insecure Deserialization?

These days, the most popular data format for serializing data is JSON, though XML is a close second. Quite a few programming languages also offer their own methods for serializing data which often contains more features than JSON or XML. In any case, problems can occur if developers program apps to treat deserialized data as trusted input, as opposed to following the old mantra from other blogs in this series, specifically: "Never trust user input!"

User input is never to be trusted because the user can insert code into those strings, which might accidentally be executed by the receiving server. And since raw deserialized data can also sometimes be accessed and exploited, it needs to fall into that same untrusted category.

For example, if a forum application uses PHP object serialization to save a cookie containing a user's identification and role, then that can be manipulated. A malicious user might change their "user" role to "admin" instead. Or, they can use the opening provided by the data string to inject code, which might be misinterpreted and run by the server as it processes the "trusted" data.

Why is Insecure Deserialization Dangerous?

It's true that this kind of attack requires some modicum of skill on the part of a hacker, and sometimes trial and error while the attacker learns what kinds of code or exploits the server will accept from their manipulated, deserialized data. That said, this is a commonly exploited vulnerability because of the potential power it gives to hackers skilled enough to use it.

Depending on how the deserialized data is supposed to be used, any number of attacks, including many that we covered in previous blogs, can be employed. Insecure deserialization can be a gateway to remote cross-code injection, cross-site scripting, denial of service, access control hijacking, and of course SQL and XML injection attacks. It basically opens up a launching point, declares all the data being deserialized to be trusted, and lets the attackers try and exploit it.

Eliminating Insecure Deserialization

The safest thing that organizations can do to prevent insecure deserialization is to restrict applications from accepting deserialized data. That may not be possible or realistic however, but no worries, because there are other techniques that can be employed to defend against this kind of attack.

If possible, data can be sanitized to something like numeric values. This might not totally stop an exploit, but would prevent code injections from occurring. Even better is simply requiring some form of integrity check against deserialized data such as a digital signature, which could ensure that data strings have not been manipulated. And all deserialization processes should be isolated and run in a low privilege environment.

Once you have those protections in place, be sure to log all failed deserialization attempts, as well as network activity coming from containers or servers that deserialize data. If a user triggers more than a couple of deserialization errors in the logs, it's a good indication that they are either a malicious insider or have had their credentials hacked or stolen. You might even consider things like automatic lockouts for users that constantly trigger deserialization errors.

Whichever of these tools you employ to fight insecure deserialization, remember that at the core, this is data that might have been touched or manipulated by a user. Never trust it.

More Information about Using Components with Known Vulnerabilities

For further reading, you can take a look at what OWASP says about insecure deserialization. You can also put your newfound defensive knowledge to the test with the free showcase of the Secure Code Warrior platform, which trains cybersecurity teams to become the ultimate cyber warriors. To learn more about defeating this vulnerability, and a rogues'gallery of other threats, visit the Secure Code Warrior blog.

I'm sorry, I have to deliver some bad news.

Traditional training is dead.

Well, okay, it's not... but it probably should be. Time and time again, studies have shown that sticking a bunch of people in a classroom to learn something new, tick off a compliance task or undergo retraining is one of the most ineffective ways for people to receive an education. And when it comes to corporate training, those statistics don't improve. The Harvard Business Review published a study on the effectiveness of classroom training for new hires of large corporates, finding that this learning method took an average of eight to twelve months to get new employees up-to-speed and productive. That is a very long time to fully utilize a person's skills (and a long time to get comfortable, if you're the new hire). These days, most places don't have that kind of time; inevitably, corners get cut, people don't receive the training they need and a company loses out on a lot of value that could be attained much sooner.

It truly boggles the mind that many places still rely on classrooms, dry textbooks and mind-numbing video training to get their best and brightest on-board with company best practices or new initiatives, especially when there's a far better, more engaging and more valuable way to learn: contextual training. As it turns out, we humans are way better at retaining information when we get hands-on with new ideas and processes.

Now, when it comes to developers... we're a special bunch. From my own experience as a developer, traditional training doesn't exactly set my world on fire. Devs tend to be creative, resourceful problem-solvers who would much rather be using the tools than be lectured at in a classroom, or sat in front of endless videos of a talking head when trying to learn new information. If you look at security training in particular, there appears to be a clear disconnect in the current landscape: developers are failing to address common vulnerabilities in their code, leading to AppSec professionals tearing their hair out when they are faced with the same easily fixed problems over and over again. The relationship between those teams is strained, and developers are not given the right tools and training to stay engaged with secure development best practices. Their main objective is feature-building, but with cyber risk rapidly increasing for every company, we simply cannot afford to ignore and deprioritize security knowledge any longer.

And the best part? If developers are security-aware, those common vulnerabilities start to disappear. Risk is reduced, along with the costs of fixing late-stage bugs (and AppSec stops losing their hair by the handful).

So, what does engaging developers with contextual training look like, exactly?

Real-world examples are ridiculously powerful.

Imagine if we all had to learn to drive by watching videos on YouTube. While you can get the general idea of how a car works, as well as the sequence of events that is initiated to move you along the road, it would be virtually impossible to learn to drive well until you hop in a car and try it in-person.

Contextual training is so valuable because it puts the student in the driver's seat of whatever is being taught. When you have a real-world context for something, it makes the learning far more engaging and meaningful.

Looking at secure coding, anyone can sit through a video and understand the basics of SQL injection, but the nitty-gritty of actually solving the problem is easily forgotten when deadlines loom and features delivery takes priority. However, if it was possible to review real code examples, identify the injection and fix it as part of a training exercise, that is far more applicable to a developer's day job than trying to retain one-way information. It's also more relatable for a developer, if they see code that is similar to what they usually write, they will stand up and pay attention.

On the Secure Code Warrior platform, we've gamified secure code training, offering a wide variety of challenges in multiple languages and frameworks. The system encourages repeat play and most importantly, is instantly customizable to offer the right environment for true contextual learning.

Provide knowledge when it is most useful

According to contextual learning theory, effective learning occurs only when students process new information or knowledge in such a way that it makes sense to them, within their own individual frames of reference.

Imagine that a developer receives a list of security vulnerabilities from bug bounty programs, SAST tools, or bug-tracking software. They may be perplexed - even overwhelmed - if they've never come across these vulnerabilities before. What's worse, most reports are designed for application security experts and not developers. The information in the reports is hard to parse and often contains generic advice not directly applicable to a developer.

Recently, we've added the ability to deep-link directly to hands-on training on vulnerabilities from bug bounty programs, SAST tools, bug-tracking software and penetration test reports. Developers can immediately understand the basics and learn good coding recipes for their particular framework.

Learning in this way ensures developers are receiving knowledge and training on concepts when they are most relevant, and they are far more likely to retain that information in the long term.

Faster results, less disruption, happier campers.

With any training, an immediate context with your day-to-day activities is going to be far more powerful than attempting to apply something generic to your work. You spend less time in "study mode", or worse - having to go back through things you've already "learned" when you need an answer for something.

One of the principles of contextual training is the ability to build upon knowledge so that each component of the training adds to the previous one, allowing for a stepped process that gives participants a pathway to mastery. Again, this is something we support on our platform, with a belting system similar to what might be found at a karate dojo. Everyone starts off a white belt, before progressing to the coveted black belt, or, "security champion" level after putting in the necessary hours of training and tournament participation. It's a fun approach with real-world value and practical application.

Want to retain the best talent and keep them security-aware? Give them the tools to succeed.

It's an unfortunate reality that, right now, security-aware developers and AppSec specialists are a scarce (yet vital) resource. They're also notoriously difficult to hold onto.

Cybrary conducted a survey among 3100 IT and security professionals in 2018, revealing that a key element in retaining valuable employees was investing in their training. Their findings show that companies who provide the tools and training to nurture their in-house security skills were able to retain security pros 60% more than those who didn't, and a whopping 65% of respondents preferred that training to be hands-on. Pretty neat, huh?

However, the survey results also provided a rather alarming revelation: 80% of respondents do not feel adequately prepared to defend their organization against cyber threats. Those threats are not going away, and the right training to combat the growing risk of costly data breaches and attacks is needed now more than ever. And, well, I may be biased, but Secure Code Warrior's platform could be the tool you need to spark a positive security culture, upskill and support developers with the contextual training they love and protect your organization from the bad guys. Request a demo and we'll show you more.

Sensitive data exposure has been responsible for some of the most publicized and impactful data breaches over the past few years, like the catastrophic Marriott breach wherein over 300 million customer records were stolen, and another 150 million when Equifax was attacked. There is a medium level of sophistication required, and sometimes special equipment on the part of the attacker, but it's not overly hard for a hacker to pull off in many cases, and tools exist to automate some of the attack functions.

Sensitive data exposure occurs whenever information that is only meant for authorized viewing is exposed to an unauthorized person in an unencrypted, unprotected, or weakly protected state. Most of the time this involves data that hackers want to steal such as credit card numbers, user identification, business secrets and personal information that might be protected by laws and industry regulations.

Hackers can steal sensitive information if it is stored without encryption or by indirectly attacking the encryption scheme. Instead of trying to decrypt strong encryption directly, they instead steal crypto keys, or attack data when it's moved to a non-encrypted state such as when it's being readied for transport.

In this episode we will learn:

• How attackers can trigger sensitive data exposure
• Why sensitive data exposure is so dangerous
• Techniques that can fix this vulnerability.

How do Attackers Exploit Sensitive Data Exposure?

Sensitive data exposure normally happens when sites don't employ strong end-to-end encryption to protect data, or when there are exploitable flaws in the protection scheme. It can also happen when the encryption used is particularly weak or outdated.

Hackers will often try and find ways to get around encryption if it's not extended everywhere. For example, if a user identity database stores information in an encrypted state, but automatically decrypts it when retrieved, a hacker might be able to use one of the attacks we previously covered in these blogs, such as SQL or XML injection, to order the database to perform the decryption process. Then the data would be decrypted for the hacker, with no additional effort required. Why try and break down a steel door when you can just pickpocket the key?

Weak encryption is also a problem. For example, if credit cards are stored using an outdated encryption scheme, it could be an issue if a hacker is able to use something like a local file inclusion vulnerability to pull the entire database over to their computer. If the captured data was protected using something strong like AES-256 bit encryption, then it would be much harder to break if it landed in a hacker's possession. But if weaker or outdated encryption is used, something like the older DES standard, then a hacker with special equipment such as a rack of graphics processing units (GPUs) can task them to break the encryption in a relatively short amount of time.

Why is Sensitive Data Exposure Dangerous?

Sensitive data exposure is dangerous because it lets unauthorized users see protected information. If the data wasn't important, it wouldn't be protected, so any breach of that protection is going to cause problems. It's never a situation that an organization wants to find itself facing.

How much trouble a sensitive data exposure can cause depends on the kind of data that gets exposed. If user or password data is stolen, then that could be used to launch further attacks against the system. Personal information exposure could subject users to secondary attacks such as identity theft or phishing. Organizations might even find themselves vulnerable to heavy fines and government actions if the exposed data is legally protected by statutes like the Health Insurance Portability and Accountability Act (HIPAA) in the United States or the General Data Protection Regulation (GDPR) in Europe.

Eliminating Sensitive Data Exposure

Stopping sensitive data exposure begins with ensuring strong, up-to-date and end-to-end encryption of sensitive data across an enterprise. This includes both data at rest and in transit. It's not enough to encrypt sensitive data while it sits in storage. If it is unencrypted before use or before transport, then it can be exposed using a secondary attack that tricks a server into unencrypting it.

Data in transit should always be protected using Transport Layer Security (TLS) to prevent exposure using man in the middle or other attacks against moving data. And sensitive data should never be cached anywhere in the network. Sensitive data should either be sitting with strong encryption in storage or sent using TLS protection, giving attackers no weak points to exploit.

Finally, do an inventory of the kinds of sensitive data that is being protected by your organization. If there is no reason for your organization to store such data, then dump it. Why expose yourself to potential trouble for no possible benefit? Data that isn't maintained by an origination can't be stolen from it.

More Information about Sensitive Data Exposure

For further reading, you can take a look at what OWASP says about sensitive data exposure. You can also put your newfound defensive knowledge to the test with the free demo of the Secure Code Warrior platform, which trains cybersecurity teams to become the ultimate cyber warriors. To learn more about defeating this vulnerability, and a rogues'gallery of other threats, visit the Secure Code Warrior blog.

The XML External Entity Injection attack, sometimes simply abbreviated as XXE injection, is relatively new compared with some of the classic vulnerabilities that are still making the rounds years after their inception. But it's extremely popular among hacking communities right now, and growing even more so as it racks up successes.

In fact, OWASP now lists XXE injection as one of the top ten vulnerabilities that sites need to watch out for and actively defend against. But don't worry, XXE injection isn't any more powerful than other exploits being deployed in cyberattacks. It's just a little bit newer and a little bit less understood. It can be prevented, and in fact, completely halted.

In this episode we will learn:

• How attackers use XXE injections
• Why XXE injection is dangerous
• Techniques that can prevent this vulnerability.

How do Attackers Trigger an XXE Injection?

The XXE injection vulnerability can occur when a malicious user is given the ability to submit XML code. They use this ability to create a reference to an external entity. The external reference and the code is designed to slip past an XML parser with default settings, or one with weakly configured settings.

The attacker exploits the fact that the XML standard defines the concept of an entity as a storage unit of some type, but that storage can be external or internal. Used properly, it can allow XML processors to access remote resources. More often than not, attackers use this ability to instead do things like probing the internal structure of a website, launching a denial of service attack by triggering large system processes trying to access remote resources, or even dump data from a local host to a remote one that they control " making it a good technique for exfiltrating important data like passwords or personal information contained in the XML database.

The actual code involved in the attack is often fairly simplistic, merely exploiting the entity functionality. For example, this might allow a hacker to access the master password file:

<!ENTITY hackwithxxe SYSTEM file:///etc/password>

Why is XXE Injection Dangerous?

There are a few reasons why XXE injection attacks are so dangerous, and also prevalent. For one, it's a less understood vulnerability right now. And the gains that an attacker can make by exploiting it are considerable. For one, it can allow persistent attackers to slowly map all paths in an internal network or even scan ports. Although this might take a fair amount of time, there is almost no chance that a hacker's activity will be uncovered by active defenses on the target network because they are simply sending XML code into a server that is being cleared by the trusted XML parser.

Once mapped out, attackers can use the same XXE injection techniques to capture whatever files they need, either directly stealing information or by compromising valid user credentials and using them for secondary attacks. Finally, attackers that just want to make noise and be malicious can do things like triggering denial of service attacks, ordering the application to try and access distant resources designed to bog down the system.  

Eliminating the XXE Injection Vulnerability

Because of the rapid increase in XXE injection attacks, many XML parsers are starting to disable external entities, sometimes called DTDs, completely by default. For those, the key is simply not enabling that functionality.

But even parsers that allow DTDs can have that functionality disabled. In general, a statement like the following is going to be needed to completely block it, but check your local framework documentation to get the exact code needed.

factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);

Following security principles, all user input should be sanitized and validated using application-wide filters. Don't forget to include GET and POST parameters, HTTP headers, and cookies. You can also create a whitelist of specific DTDs and commands that you want the parser to process, and disallow everything else.

While whitelisting and filtering works, because of the rising number of XXE injection attacks, it is still recommended that DTD support be completely disabled if the functionality is not required.

More Information about XXE Injections

For further reading, you can take a look at what OWASP says about XXE injection attacks. You can also put your newfound defensive knowledge to the test with the free demo of the Secure Code Warrior platform, which trains cybersecurity teams to become the ultimate cyber warriors. To learn more about defeating this vulnerability, and a rogues'gallery of other threats, visit the Secure Code Warrior blog.