Tala Blog

Secure Code: Why and How to get your teams to write secure code

Rajesh Kanungo - Nov 21, 2017 9:48:00 AM

Copyright (c) Rajesh Kanungo

If you like this article, feel free to share it!

What if you walk into your CEO’s office and tell him you could get rid of 95% of security bugs in your software by doing just two things?  What would your CEO say?

Some fun facts (short version)

1.     90% of security bugs are due to input validation errors?  Examples are bounds check, SQL validation, HTML/JavaScript checking, etc.

2.     5% of the security bugs are due to ignoring of return values.

Full Disclosure:  Much of what I write about is really based on a lot of hard work of countless engineers and managers at Sling Media, Itron, TrustTone Communications,Echostar, etc.  Any success I had in moving organizations was due to teams coming together.

What I will cover

I will cover the writing of secure code at a high enough level that executives, managers and engineers can see the benefits of the approach.

What I will not cover here i.e. full SDLC

I will not cover full SDLC as that is generally a much bigger issue.  I will not cover many of the security design principles and cryptographic algorithms.  I will also not go into the actual details of techniques like mitigation of integer overflow attacks, buffer overflow, attacks.  I generally cover all the topics in lab training and there are many books on the subject.

Some Fun Facts (long form)

1.     90% of security bugs are due to input validation errors?  Examples are bounds check, SQL validation, HTML/JavaScript checking, etc.

2.     5% of the security bugs are due to ignoring of return values.

3.     99% or more bugs are in our own software; i.e. we create our own bugs.

4.     Secure Code is reliable: With all the error checking, documentation, static and dynamic code analysis, third-party scans, etc,. code will be more reliable.

5.     Organizational Pushback:  Most organizations and teams are driven by features and security and secure coding issues are generally an afterthought; there is active organizational resistance at all levels.  It is more than just inertia.  Sometimes they are afraid of the bad news hitting the stock analysts.

6.     Security Issues cost the enterprises a lot of money and damage their brand. However, prevention is not directly measurable except that there are now lawsuits that are being used to get companies to do the right thing.

7.     Unreadable code is hard to audit:  It is hard to audit the code for security issues if you can’t understand it.

8.     Unreadable code is a business risk:  When code is not readable, you are beholden to the engineer and his quitting can lead to disaster including security issues.

9.     Many organizations fight Static and Dynamic Code Analysis Software:  These automated tools can find many secure coding issues.  However, teams avoid them because they think that they are too intrusive, too time consuming, etc.  

10.  Secure Coding Guidelines are LONG, DULL, BORING, CONVOLUTED, etc.  

So Let Us Try to Address These Issues

1.     Start from the Top:  The CEO, the CFO, the Board should require security not just pay lip service to it. Some positive things they should do:

  • Track Security issues:  In both Sling Media and Itron, the CEOs were completely aware of security issues and helped everyone fix them.
  • Security should be one of the KPI’s for all managers, teams and personnel.
  • Reward good teams.
  • Start SMALL: find teams that are self motivated and/or are providing services or products which need to be strengthened.
  • Invest in Tools, please.
  • Invest in a good security team which does not report to engineering.

2.     Starting Small:  You have to make the problem set small but there is a limit …

  • Provide Secure Coding Training.  There are many SANS training courses and books from SEI and others.
  • Coding Guidelines Extension:  Extend your coding guidelines to have security features.  Some useful sources are:

 i.     Secure Coding in C and C++, 2nd edition, Robert Seacord, https://www.cert.org/secure-coding/publications/books/secure-coding-c-c-second-edition.cfm

ii.     SEI CERT C Coding Standard: Rules for Developing Safe, Reliable, and Secure Systems (2016 Edition)

iii.     SANS Top 20 …

iv.     Static Code Analysis tools have their own listing.

  • Create a Security Checklist:  Reduce the security requirements to a checklist.  A secure coding checklist is immensely more useful to non security engineers who just want to do the right thing.
  • Start with a very small team:  A good team size is 4 engineers at most. Be ready to review reams of code. The security team needs pitch in.
  • Use Static Code Analysis Tools:  Get your IT to install it or do it yourself and run it.  
  • Pick only a few files in a module to fix based on code scan results.  Some criteria:

                                               i.     Most number of security issues.

                                             ii.     Most complexity.

                                            iii.     Network facing.

                                            iv.     Protects most valuable assets.

  • Ensure that the fixed files are clean:  

                                               i.     They pass static code analysis cleanly.

                                             ii.     They are well documented.

  • Ensure that new bugs are not introduced by writing good tests if they were missing.

3.     Medium Organizational Level Objectives:  Perfect Security is a never ending quest.  

a.     Ensure that the goals of ‘good enough security’ is articulated properly.

b.     Marketing, Sales, Support, Operations, Engineering, Manufacturing, QA, etc. MUST have Security KPIs otherwise Engineering will feel misled and penalized.

c.      Program Management MUST be able to demand features and security metrics,

d.     The independent security group must be able to validate the security of the product or services.

e.     Spread the the knowledge acquired to rest of the organization.

f.      Use external vendors to validate your security quality periodically.

Conclusions

I have provided a high-level approach to improve your code security.  You may contact me for more details; I have many stories about wins and losses. You can also contact me if you feel frustrated; it seems like for we take 10 steps backwards for every step forward.

 

Acknowledgements

I can’t thank everyone but some of the main people who helped me were: 

1.     Sling Media: Raman RV, Raghu Tarra, Ilya Anastis, Aparna Akella, Gireesh M., Senthil Doss, Aravind N., Andrey Abramov, Arun Gangotri, Alex Huang, and many more.

2.     Echostar: Geoff Kemp, Kyle Haugsness, Mark Templeman, Evan Anderson, and many more who helped me in the setting clear goals.

3.     Itron: Ben Loomis, Ido Dubrawsky, Michael Stuber, Ishtiaq Rouf, Sakib Muhamed, Scott Howard, Greg Barrett, Janice Tucker, Taresa Nephew, Kris Ramberg, Karen Livingston, Jackie Batson, Ryan Wilson, Jerry Hicks, etc.

I must have forgotten many people.  My apologies.

Previous Post

Simple ECC implementations and a Simple Approach to Side Channel Attacks

Next Post

IoT Minimum Viable Security for a Minimum Viable Product

0 Comments