Security is in the news constantly these days. Systems are being breached, information leaked, and identities stolen. With more penetration testers and security experts in the field than ever before, it makes some people wonder where the problem is.
I believe that one of the problems is the lack of a security mindset in our software development circles. Underlying all of these security problems is a mentality that says,“Code now, patch security later.”
This needs to change.
Maintaining a Security Mindset
But what exactly is a “security mindset”?
A security mindset involves thinking like a malicious intruder. It’s a state of mind in which everything you do falls under the scrutiny of potential abuse. The question should never be “will people try to hack this?” but rather, “what would happen if this were hacked?”
Security is never an absolute. Rather, it’s constituted as a series of levels. We must choose an appropriate level of security for each project we work on.
For example, implementing two-factor authentication within your Flash version of Pong is clearly overkill, but not sanitizing inputs for a website login is negligent.
It is important to be intentionally aware of what level of security is appropriate for the project you are working on. This can be determined with a few basic questions:
“What kind of data am I dealing with?” Remember that client data should always be kept private and on a need-to-know basis, even simple things like email addresses. “What other systems could this give access to?” Many hacks of critical systems occur through vulnerabilities in seemingly innocuous ones. A great example of this would be the many simple wordpress plugins that have been used to gain elevated access to sites and servers. “Do my security measures make assumptions about the user?” In a world where all users had really great passwords, salting would be far less important than it is. We cannot make assumptions about the quality of users’ passwords, as providers have more security responsibility than end users. “What third party resources will this project rely on?” Understanding your dependencies can prevent security breaches through third party software.Asking basic questions like these is what the security mindset is all about. It is as simple as taking a step back and trying to think about things from another angle. It doesn’t take long to do, and it can save a lot of trouble in the long run.
Security for Embedded Software
Embedded software is one of the areas with a big issue of ignoring security. A programmer wouldn’t dare think about ignoring security when creating a login portal for a bank, but that same developer may not think about security at all when writing the code for a usb keyboard.
My wife is a Type 1 diabetic and is reliant on an insulin pump. For those of you not familiar with them, this is a small device connected to her by tubing and a needle in her skin at all times. The pump contains an insulin reservoir that delivers the life-saving hormone to her throughout the day. It has Bluetooth capabilities that allow her to control the insulin dosage from her blood glucose meter.
Now, what if the developers weren’t security minded and set the same default password for the Bluetooth connection on all of these pumps? Worse yet, what if the connection isn’t encrypted and doesn’t require a password at all?
They may think, “Who would want to hack an insulin pump?” The answer is, anyone who likes a challenge.
Take a look at history and you will find that people used to hack the phone companies with “boxes,” like the beige box that allowed them to make calls for free. People will because they can. We have already seen issues like this in the automotive industry.
Something as simple as the car’s auto parallel park feature provided a vulnerability that allowed hackers to control the steering wheel of a 2015 Jeep.
The developers didn’t have a security mindset when writing many of these embedded features, and the result was a very expensive recall for Chrysler.
What’s the Cause of Indifference to Security? EducationI believe that one of the main causes of this problem can be traced back to the computer science programs of universities.
Not enough security classes are offered to undergraduates. These classes should not only be more available, but made mandatory for a student to graduate with a degree in the software development field. Teaching students about specific common vulnerabilities such as database injection can be helpful. It is far more important, however, for our education system to teach students to “think like a hacker.” It is similar to the “give a man a fish, feed him for a day; teach a man to fish, feed him for life” proverb. By teaching the security mindset and mentality, we can better prepare the next generation of developers.
I would also encourage all computer science students to participate in bug bounty programs, as this could give great real-world experience in this area. This would help the next generation of programmers to approach things from a security mindset, preventing issues before production. It goes right along with the old saying, “An ounce of security is worth a pound of patches,” or something like that.
The Responsibility to Invest in SecurityAnother barrier to better security lies within the companies themselves.
It seems that many companies do not see the value in investing resources to increase security in the first place. I worked for a company as a helpdesk tech for about one and a half years. In that time I wrote some software to make the job easier. The company had over 1,000 machines spread across 35 states to be managed, and a meager team of five helpdesk workers.
If they needed to make a company-wide change on the machines, they had us five workers remote into them one by one and apply the changes. I wrote patch deployment software that would allow us to deploy the changes via scripts uploaded to our server.
While I was doing this, my code was never once reviewed by another worker. While I appreciated the trust, the potential for abuse or mistakes was very high. They never once questioned the security of my system.
After the first couple of versions were up and running, I myself realized that if the FTP Server was compromised, the attacker could upload their own scripts to be executed on these machines (many of which were used for retail point of sale). So I took it upon myself to implement asymmetric authentication of the files so that only the scripts we signed with our private key would be executed. That company was quite fortunate that I didn’t abuse their trust!
However, to implement this security measure, I had to scrounge for extra time because they did not want to “waste” the time it would take. In this case, it was the management who were not being security minded, not the programmers.
This is why it is so important for the security mindset to flow from the top down. Some people do what is asked and no more. At some workplaces, taking the initiative to improve security can actually get you in trouble.
What so many managers and business owners fail to see is that placing security first will actually improve profits, by creating reliability and trust with the customer. Target alone lost over 160 million dollars due to its credit card breach , to say nothing of faith lost in its brand .
While not all managers and owners can be taught all of the technical details of modern security, the principles of being security minded and the overall importance of security can and should be taught to anyone in a leadership role of a business.
Early Is Better Preempt PatchingThere are many important things to consider whenbeginning a project. It is our job to make security one of those considerations. Patching should be viewed as a last resort, rather than an excuse to neglect security during the initial phases of the project.
Ignoring security adds just as much (if not more) to your technical debt as unfixed bugs. Very often, customers simply miss needed patches altogether. Furthermore, patches also have the potential to break other features, as security patches need to be written and deployed quickly, which makes testing difficult.
Respecting the End User
At the end of day, it all comes down to how much we respect our users. It is easy to become jaded about users, but they are the ones who ultimately keep us employed. They are the reason for our existence as software developers, and as such their security and user needs should always come first on our to-do list.
It is impossible to prevent all security breaches. However, it is up to us as developers to start pushing our employers and educators to recognize the importance of a security mindset from the start.
I believe that if we work together to put the user first and prioritize security from the top down, we will greatly reduce the instances we see on the news of major hacks that hurt companies and customers alike.
So the next time you are working on some mundane and seemingly unimportant piece of code remember, security starts with you.
ResourcesFor up-to-date security news, check out Krebs on security . If you are interested in bug bounty programs, HackerOne is a great place to start. You can also search the National Vulnerability Database to find the latest security exploits. Finally, 24 Deadly Sins of Software Security by Michael Howard, David LeBlanc, and John Viega covers many of the most common security issues in software development.