This site will look much better in a browser that supports web standards, but is accessible to any browser or Internet device.
There are numerous issues that you need to consider when developing almost any software. If you are working on software that connects to a network in any way, security is yet another thing that you need to consider.
To introduce this series on Designing Secure software, I'm going to talk about something that normally gets left out of discussions about security: threat assessment.
But first, let's go over how security discussions usually play out...
Many companies, or even just development groups, don't think about security until one of a few things happens:
In the first two cases, the result is normally yelling at the development staff to find out why they didn't make things secure. The other two cases normally start with an emergency meeting to ask Are we safe from that?
In most cases, little to no thought was spared up front for security. Everyone was focused on features, usability, look, and other issues that seem to translate directly into dollars. As usual, hidden issues don't get much attention unless they go wrong.
Once the emergency happens, the powers-that-be want the development staff to smear some security on the system to protect from attack. The big problems with this approach are:
I'll cover the myth that a system can be absolutely secure in a later post. Suffice it to say that if money is no object, a sufficiently powerful and motivated attacker can get into any system.
Which leads to the second point, what kind of attackers are you trying to protect against? To a large extent, the kinds of attackers you expect determines the kinds of attack you are likely to see. Some of the possible attackers you might need to protect against include:
This is not a complete list, but it does a fair job of covering the range of attackers you might face. The kinds of attackers you expect determines what kinds of security you need.
If your service serves a community of people who discuss different varieties of carnations, you are not likely to be targets of organized crime, Chinese hackers, or the FBI. There's not much reason for a large hacking group to go after your community. You might be the target of vandalism or someone trying to plant malware on your site, but those attacks are a much different caliber than a high-end, organized attack.
You need to determine what is important about your site that you need to keep safe. Are you storing passwords, credit card numbers, or personal identification information on your clients? You probably need to be more careful than if you are storing a user-chosen alias. If you are storing serious financial information, you need to be even more secure.
What would happen if someone gained access to all of the information you have on your customers? Would it be embarrassing, a source of financial difficulties, or life-threatening?
Let's look at a few scenarios to see how you might make some decisions.
Let's start with our example from the last section. Say you have a site that supports a group of flower enthusiasts chatting about carnations. What you have determines who might attack and how.
If you have a username and password for each user to allow them to post, there are a small number of possible attacks. The first is malware or malicious links. Anywhere your users are allowed to post something that you can display will need some level of protection from this treat. But, this applies to almost all sites. The important part is what is special about your site.
Given the known breaches that have released large numbers of passwords, your passwords are a target. Since, in this example, there is no email address or real name associated with the account, the passwords are only mildly valuable.
If your passwords are not stored in the clear, the biggest threat to your system is people hacking in and posting something that harms the reputation of a user in your system.
This would probably not attract the attention of anyone with a large amount of resources. Although, you might have to watch out for the sunflower hacking squad. They might want to deface your pages as part of their ongoing campaign to take the most popular flower spot.
Let's say we increase the amount of information on the carnation chat site. In addition to the username and password, let's say you include contact information: real name, physical address, and email address. You use this to send personalized offers for flower shops.
This makes the passwords more valuable (many people have one email address and use the same password on multiple sites). The email address is always of interest to spammers. The physical address and real name together gives more information for potential identity theft.
Notice how a small amount of information significantly increases the potential threats.
Say the site has added the ability to buy carnations and have them shipped to you. If you store credit cards, you have just become the target of larger groups. Organized crime, larger hacking groups, small-timers trying to make a reputation will all be interested. You now have something that translates directly to cash.
The more advanced the attacker, the more effort and expense will be needed to secure the software. Identifying who is likely to attack your software allows you to provide reasonable security without spending too much effort.
What you have and what you do determines who would be interested in attacking you. Identifying potential threats determines how much effort you need to put into securing your (and your users) information.
Putting too much effort into security, which could cause a project to miss a deadline or fail completely.
Posted by GWade at September 1, 2015 07:55 AM. Email comments