The alarming state of secure coding neglect
oreilly.com
oreilly.com
Developers tend to think of security as about avoiding coding mistakes, and that's reflected in their idea that security is about pen testing, code review, tools, etc. Any security professional will tell you that these are valuable but only a small part of the big picture. Take a look at Microsoft's SDLC for a wider view of what it takes to weave security into every aspect of software development[1]
Probably the single most valuable thing most development organizations could do to improve security of applications is to do threat modeling[2][3]. It's especially valuable in the early stages of application design, but it can be applied at any time. Threat modeling can increase awareness of how an application's security assumptions interact with its overall architecture. Thinking through your application's threat model systematically is the first step to prioritizing mitigations.
Unfortunately, this is voodoo to most developers even though it really should be an intrinsic part of designing application architecture. I've heard people say there's a mental block because the kind of thinking required for security is almost the opposite of that required to design and construct systems. I don't believe that though. I think it's mostly a matter of training and historical accident that security is even a separate discipline. It shouldn't be.
[1] https://www.microsoft.com/en-us/sdl/
[2] https://msdn.microsoft.com/en-us/library/ff648644.aspx
[3] https://www.owasp.org/index.php/Application_Threat_Modeling
What changed in computing is the internet is the worlds largest 'city' by a huge margin and people can mostly automate checking to see not just if the door is locked but if the lock is of poor quality. Clearly in that situation laws are going to have limited value, but because they have been so successful in the past it's really hard to get out of that mindset.
PS: Sure, there is crime, but compared to say 20,000 years ago the odds some kills you and takes your stuff next year is tiny.
From across the world. Lack of proximity overturns the effectiveness of millennia of social norms.
I think it is a good idea to make hacking be viewed as heavy offense instead of fun and games. Of course you can do it on your own servers for fun but do not touch what is not yours.
I think people have an implicit threat-model that their home/business would be robbed by a cat burglar, rather than a robber. Because, if they, as a regular person, wanted to steal stuff, cat burglary is what they'd do, because it makes it a lot easier to get away with.
People don't realize, of course, that thieves are usually people rather desperately in need of money—people who need a short-term solution to an urgent problem—and so not only don't care as much about the long-term risk of their actions, but really don't have time to "case the joint" or come up with a stealthy solution.
(Full disclosure: I work in the computer security industry.)
If you really want security, it's something that every programmer should be thinking about, at least in the back of their mind, on every line of code they write.
And if it's possible, And we already have a few such tools(like say scala lift, ARM mbed ) but somehow haven't yet became popular, why is that ?
I have had to do several 'security' training sessions. I understand it intellectually, but they don't instill a deep understanding.
Start out with things like, "don't leave your telnet port open" which seems obvious, but apparently is hard for a lot of people. Then from there lead to a reasonable understanding of metasploit.
Unless you're doing this with some level of competence, it's probably wrong.
Making line developers competent at security is a nice idea, but you have about 27 other things people have said that developers should be good at alongside of security.
Because an API that provides security for free is a laughable proposition.
Puts me in mind of the sort of systems you create working with the military: every line of code not only has to do its job, but has to be hardened against both electronic warfare (e.g. memory corruption from radiation from a maser) and cyberwarfare. It really does feel all of a piece when you get into that mindset.
But because the interfaces and protocols used for the creation of web services require remote access and hostile input suddenly you get an army of application programmers doing systems level work.
So, to further your point: historically it was a separate level, the web has squashed systems programmers and applications programmers into the same layer of the sandwich.
Of course you should know the basics, in fact, you should know everything otherwise what you build will be insecure. But traditionally the 'systems programmers' took care of those details for you and you could write your application in a wonderful trustworthy world. Until ~1992 hacking into a remote system was remarkably hard because there was far less software and that software had been vetted extensively before it was deployed by people who knew what they were doing.
Now it's a free-for-all where everybody with $5 to spare can spin up a VPS and slap some insecure bunch of webstuff on it or cook it up themselves. That's a completely different situation.
Secondly Moor Law consequences where visible after few years. Even MS did not predicted PC boom, everyone now have few computers. Both in terms of performance and availability of hardware we see it massive shift.
It is extreme difficult to add security to system afterwards. In Last Kerberos vulnerability was fixed like last year (Kerberos is used from Windows 2000). Wordpress is still not secure... OpenSSL have something every year.
> it was deployed by people who knew what they were doing.In most fields there is little incentive to change things when the company itself isn't too affected in case of hack. Stocks go down for a week, then back up. General population doesn't seem to care enough to stop using the services, and does not understand enough about privacy/value of their data/need for encryption. So why would a company care ?
If being "ethical" and more devoted to privacy becomes a trend, perhaps there will be a stronger drive to follow security experts' advice. Did Whatsapp get a surge in users after enabling end-to-end encryption?
https://hbr.org/2015/03/why-data-breaches-dont-hurt-stock-pr...
This is correct. As long as the risk isn't too high then companies will just take the risk and accept a hack as the "cost of doing business". Much like Goldman Sachs expects they will get fined by Governments, but they don't care because the money they make far outweighs the fines imposed.
This is steadily changing. I've had a few recent engagements where i've been asked to evaluate the security practices of potential partners and suppliers and in one case the result affected a sourcing decision.
I can see this becoming more common, which could eventuate into a credit-reporting like bureau setup to audit security and privacy practices.
https://www.out-law.com/en/articles/2016/may/gdpr-potential-...
Personally, I believe that if it's negligence, there should be compensation - they lost something that belongs to you and is of value. But few people seem to really care. The info of 1 billion yahoo accounts was hacked, but who cares? Until that changes, the problem will continue to exist.
this could lead to serious limitations on legitimate future progress including on anything built using statistical methods that require large training data sets.
If companies were trustworthy with data, than that wouldn't be an issue. Why should they get a free lunch on my dime?
[1] https://research.googleblog.com/2017/04/federated-learning-c...
Some level of public education is also required I think, to make people aware of the value/threat of just giving everything up every time someone asks for it.
If protecting personal information limits or slows some progress, so be it. Also it could still be done, just more carefully.
Most machine learning is done against anonymous dataset and works fine.
And really the same is true for any company that has any sizeable PR problem, regardless of the cause. Examples:
- Yahoo
- Uber
- United Airlines
- Target
A good start would be to stop using C and C++ for new projects, and generally try to eradicate undefined behavior at all levels of software. There's a lot of really great software written in C and C++, and it would be a huge undertaking to replace, say, the Linux kernel with something written in Rust or Swift or some language that hasn't been invented yet. I think the eventual benefits may greatly outweigh the costs, but it's a lot easier to sit in a local optimum where everything is comfortable and familiar than to set out on a quest to, say, formally verify that no use-after-free errors or race conditions are possible in any of the software running on a general-purpose computer with ordinary applications.
You also have to meet them where they are, not get them to change their ways to suit yours. Otherwise, you're adding resistance, and you'll fail.
Ref: http://www.telegraph.co.uk/technology/sony/11274727/Sony-sav...
It's not good, but I can see why, after a few of these experiences, proactive security gets dropped off the priority list.
PCI auditors work to a fixed standard and can be negatively affected if its found that they deviated from it, so there's a strong incentive for them to be picky. When combined with the fact that it's hard to have a standard that reflects the reality of good security practice, you end up with well the current PCI process.
The problem you're describing isn't really (I'd say) one that came from the IT Security industry though, it was the card issuing companies who set the PCI DSS standard and them that mandated the compliance process. Auditors are just carrying out those requirements.
Basically, finding pragmatic security people that can balance "perfect" with "real life" is hard.
I've seen quite a few companies where any breach of security is held to be the "security team's fault", so they have an incentive not to accept risks (limited upside if they accept a risk, alongside a large potential downside if a breach/incident happens as a result)
Getting past that really requires a culture where security is the responsibility of all people in the organization and there's no finger pointing in the event of a breach/incident.
I'm afraid that the InfoSec community has been unsucessfully persuing the idea of "RoI" for security activities for a long time (I remember debating the idea 10+ years ago..)
Also the idea that increasing breaches would drive good practices seems not to have taken root that much, probably due to breach fatigue and the fact that most companies who are breached don't take any serious financial hit.
Realistically the most likely way to improve this situation is for it to feature more heavily in contracts and perhaps regulations.
Having a contractual requirement to carry out specific activities relating to code quality/security can drive them as there's a clear monetary cost of not doing so.
Also there's a big negative externality in that a lot of the costs are borne by users of the app/system and not necessarily the developers, but due to a lack of liability for software development and security breaches that isn't taken into account by many companies
I've always suggested they focus on confidence in control of assets and IT. The upper management are usually control freaks that like knowing what's happening is what they want to happen. A good, security program puts them in control of the businesses assets. A bad, security program puts a 14 yr old troll or competitor wanting their marketing/I.P. in control. A list of their asssets, esp those easy to move, next to the cost of a reasonable security program is next move.
I'd love to see more data on attempts at doing this along with the responses. I know the scheme has already worked for people selling life insurance. I learned it from one of them. Might help on security since ROI is a dead end for most companies.
Why? Money, obviously.
1. employing security engineers who know what they are doing is EXPENSIVE.
2. third party pentests are expensive.
3. if there isn't an open source tool available, all of the software in the security area is SUPER expensive.
No company, especially small or medium size, is going to spend that kind of cash without a real motivator.
Even if you do EVERYTHING you should be doing, you will still have vulnerabilities. Its a loosing game.
If a pharmaceutical company releases a drug that causes negative side effects, lawyers are happy to sue the company on your behalf for free.
But software engineering is a discipline where no license is required, and now thanks to informal educational institutions like coding camps, not even a degree is required. You can ruin the lives of millions of people but always hop around and get another job.
Companies maximize their margin saving money on security (and other non-functional requirements), and expose customer sensitive information to significant risks with no accountability. A statement like "Sorry! we got hacked, your SSN and credit card information is now being sold by the bulk in an .onion site!" would do. We as consumers should punish those incidents more aggressively and demand a reasonable cause.
The product-driven minimum-viable-product lean-agile full-stack get-it-done culture of spaghetti code bases without security needs to die now. It's highly profitable and the preferred business model for many, yes. Is it ethical? hell no. Stop doing it. In those cultures, security is treated as "tin-foil hat paranoia" and laughed upon, and put into some "nice to have"/"maybe some day" list, with the lowest priority.
A security bug can make it into any software. But if you assembled a team of coding camp guys or fresh graduates to work on a banking platform or making an IoT pacemaker you deserve to be sued for neglicence.
Unfortunately because software is a relatively new activity compared to others, there is no established legal framework around it and that needs fixing.
Of course, there are things out there which can help a business to minimise these risks and to try and catch these potential coding horrors before they're put in-front of the general public:
- Static Code Analysis (sometimes referred to as source code analysis) is sometimes a quick win here, but of course not the silver bullet. Sometimes a bug cannot be easily identified by just looking at code for common mistakes, it takes a skilled eye or even dynamic analysis for it to be spotted. However, static analysis can be added into your production pipeline and workflow, checking on each push for any newly added vulnerabilities!
- Automated vulnerability scanning/testing is also something else which can be done in-house usually, with the right tools. There is no reason why you shouldn't be running various security scanning tools against your application during testing/pre-production, such as web application scanners or even fuzzers.
- Go external, and get a 3rd party to penetration test your application if it requires that level of scrutiny. There are plenty of smart folks out there who do it day after day who can do this for you.
You can also deploy thing post deployment of course (depending on what you are coding!), so for web applications, a WAF (web application firewall) is sometimes useful to stop the vast majority of automated attacks. The alerts from this will also give you a very good idea of what is out there and at what scale you are being targeted. I'm currently working on a side project [1] which is to try and identify breaches once they have happened, as unfortunately they are almost inevitable. It isn't always your code which lets you down! It may be a dependency or library, or even a simple phishing email. Put simply, my project produces a canary to add to your user base, that we'll monitor continually for a number of tell-tail signs that someone else may have a copy of your data.
At that point, it's time to invoke your incident response process! Or... get someone in to run that process for you.
[1] https://breachcanary.com - If you get this far, I would absolutely love any feedback.
Likely one reason is cost. When each individual tool costs 10k+ with the vendors trying to throw in consulting, it adds up.
Sorry, I should have said that to begin with.
No, but civil engineers say stuff like "What's the likelihood that a 9.5 earthquake will his this area? What about a 5?" and model their designs on that. That's the point behind threat modelling - if a nation state actor decides they want to 'hack your Gibson' that's one thing, but if you're a bank than it may be that your most likely threat is employees or contractors stealing customer data. So you put your effort into protecting against those threats as well.
We could be writing a lot of verified code, if we wanted.
But crucially, it's a skills gap -- not an intelligence gap -- that stands in their way. For most properties, writing verified code doesn't require that much more intelligence than writing normal code. Different skills, but in most cases not much more intelligence.
But I don't think a skills gap is the most pressing barrier. There is an intrinsic difference in difficulty between stating conjectures and proving theorems. There's no silver bullet here, including either education or raw intelligence. The latter is, intrinsically, more difficult and more time consuming.
Stronger type systems help a lot with common security problems. Memory safety and a system to express taint of inputs eliminate a huge class of potential problems. They are still very, very far from correctness proofs that could catch actual logic bugs.
object popsicle as DeepFrozen:
to getFlavor() :Str:
# Obviously immutable.
return "lime"
to getObservedColor(eye):
# The eye might not be immutable, but that's still okay.
# All that's required is that this object not secretly stash the eye.
return eye.observeCMYK(38, 0, 78, 1)
OpenSSL is not a protocol. It is an implementation of TLS. Other implementations were immune to Heartbleed.
1. Class action lawsuits to sue companies who have data leaks.
2. Companies take out insurance for being sued for data leaks.
3. Insurance companies impose security requirements in order to provide coverage.
The costs of dealing with breaches, no matter how demoralizing, never seem to justify
the extra time and money that good security requires. Additionally, although a security
flaw is sometimes traceable to a single line of code—as in Apple’s famous “curly braces”
bug—breaches are often a simultaneous failure on several levels of the software stack
and its implementation. So each company may be able to shift blame onto other actors,
and even the user.
Check us out at https://oneupsecurity.com if you're interested in secure software development.
Always great to chat with businesses who are passionate about security.
I wonder how that will work out with e.g. self-driving cars.
"We can't do that because it would mean we would have to re-test the codebase, meaning we'd have to test-drive the car for hundreds of thousands of miles."
"Can't we take a shortcut? I believe the change is quite innocent. And the competitor already has this feature."
"Ok, sounds reasonable. Make the change."
Tip: They do not.
"Oh no! Now we will need to do x and y and z and it will cost x dollars"
"Well we could adjust the software.."
"Sounds great!"
Yep, car industry...
Look at what happened last week with Netflix. It didn't involve user data, but they got hacked and their stuff leaked and then what? Everyone just shrugged. No big deal. I mean probably some people are getting yelled at internally, but otherwise the situation is clear: we pretend to care about this, but we don't care about it.
Imagine being a security advocate in an organization in this environment. You get to convince business people to spend money so that something doesn't happen, which even if it does happen, will result in embarrassing headlines for a day. Not exactly a convincing case!
0) The majority of programmers at this point in history are novices. Src: Joe Armstrong.
1) There is very little formalized training except in some enterprises. Many outsourcers invest very little in training and expect staff to learn on-the-job.
2) Large enterprises with immense codebases with many committers easily become Tragedies of the Commons without active code reviews and high standards.
3) There is very little standardization (convention over configuration): many languages, many non-orthogonal coding styles/language features.
4) Security seems like a non-value add activity... until there's a major problem. (Non-proactive development/CMM.)
5) Offensive and defensive sec require a different, acquired skill-set and engineering mindset from simply implementing features and fixing bugs.
There are GUI tools for setting these options, but they're absolutely atrocious. You may as well be trying to program a guided missile.
The answer has always been professional licensing.
And no, just because there's always a new flavor of the month language or framework, doesn't mean the fundamentals change all that often.
* Sanitize inputs * Secure data at rest and in transit * Never store secrets in plaintext * Set up IAM properly for your organization * Use 2FA whenever possible * Principle of least access * Update frequently
Why, again, can't we conditionally license professionals on knowing the basics, and threaten disbarment for knowingly neglecting security?
That's only the answer if you're asking people who have no real experience in security. Those who do are more likely to tell you that will only make the problem worse.
Professional licensing for writing or operating software will never work, and if it does, it will be extremely harmful.