Three roads to product security

three-roadsI mentioned previously that there are three ways to secure a product from the point of view of a product manufacturing company. Here is a little more detailed explanation. This is my personal approach to classifying product security and you do not have to stick to this but I find it useful when creating or upgrading company’s security. I call these broad categories the “certification”, “product security” and “process security” approach. Bear in mind that my definition of security is also much broader than conventional.

The first approach is the simplest. You outsource your product security to another company. That external company, usually a security laboratory, will check your product’s security including as many aspects as necessary for a set target level of security assurance and will vouch for your product to your clients. This does not have to be as complicated and formal as the famous Common Criteria certification. This certification may be completely informal but it will provide a level of security assurance to your clients based on the following parameters: in how far the customers trust the lab, what was the target security level set for the audit and how well the product has fared. Some financial institutions will easily recognize the scheme because they often use a trusted security consultancy to look into the security of products supplied to them.

Now, this approach is fine and it allows you to keep the security outside with the specialists. There are of course a few problems with this approach too. Main problems are that it may be very costly, especially when trying to scale up, and it usually does not improve the security inside the company that makes the product.

So, if the company desires to build security awareness and plans to provide more than a single secure product, it is recommended that a more in-house security approach is chosen. Again, the actual expertise may come from outside, but the company in the following two approaches actually changes internally to provide a higher degree of security awareness.

One way is to use what I call “product security”. This is when you take a product and try to make it as secure as required without actually looking at the rest of the company. You only change those parts of the production process that directly impact the security and leave alone everything else. This approach is very well described by the “Common Criteria” standard. We usually use the Common Criteria for security evaluations and certifications but this is not required. You may simply use the standard as a guideline to your own implementation of the security in your products according to your own ideas of the level of security you wish to achieve. However, Common Criteria is an excellent guide that builds on the experience of many security professionals and can be safely named the only definitive guide to product security in the current world.

Anyway, in the “product security” approach you will only be changing things that relate directly to the product you are trying to secure. That means that there will be little to no impact on the security of other products but you will have one secure product in the end. Should you wish to make a second secure product, you will apply the same.

Now, of course, if you want to make all products secure it makes sense to apply something else, what I call “process security”. You would go and set up a security program that makes sure that certain processes are correctly executed, certain checks are performed, certain rules are respected and all of that together will give you an increase in security of all of your products across the company. Here we are seeing an orthogonal approach where you will not necessarily reach the required level of security very fast but you will be improving the security of everything gradually and equally.

This “process security” approach is well defined in the OpenSAMM methodology that could be used as a basis for the implementation of security inside the company. Again, OpenSAMM can be used for audits and certifications but you may use it as a guide to your own implementation. Take the parts that you think you need and adapt to your own situation.

The “process security” takes the broad approach and increases the security gradually across the board while the “product security” will deliver you quickly a single secure product with improvements to other products being incidental. A mix of the two is also possible, depending on priorities.


Cheap security in real life?

Security concerns are on the rise, companies are beginning to worry about the software they use. I received again a question that bears answering for all the people and all the companies out there because this is a situation that happens often nowadays. So here is my answer to the question that can be formulated thus:

“We are making a software product and our customer became interested in security. They are asking questions and offer to audit our code. We never did anything specifically for security so we worry what they might find in our code. How can we convince the customer that our product security is ok?”

There are, basically, three approaches to demonstrating your product security if we take that question as meaning “how can we make sure our software is secure?” Unfortunately, the question is not meant that way. Unfortunately, the company producing the software is not interested in security and the meaning of the question is rather “how can we make the customer get off our backs while we keep producing insecure software?”

Thatkey under mat boils down to the switch from “security by ignorance” to “security by obscurity”, as I explained in one of my earlier posts titled “Security by …”. That is, of course, the cheapest possible solution in the short run. However, it does not eliminate the risk of company suddenly going bankrupt due to a catastrophic security breach in one of its products. Sony Corporation lost $190 million during their PlayStation Network hiccup a few years back. Can your company survive this kind of sudden loss? Would it not be better to invest a few hundred thousand in product security to ensure the continuity of your business in the long run?

But nevertheless the question was asked and what is a company to do when it is not willing to invest in a security program? When a company insists on a quick and dirty fix?

The advice in this case is to go along with your customer’s wishes. They want to audit your code? Excellent, take the opportunity. A code audit, or, rather, they more likely mean “white box penetration testing” in this case, is an expensive effort. At a bare minimum, you are looking at about forty man-hours of skilled labor, or fifty thousand euro or dollar net expense. Are they willing to expend that kind of money for you? Great. Take them up on their offer.

Oh, of course, they will find all sorts of bugs, security holes and simply ugly code. Take it all in with thanks and fix it pronto. You will get a loyal customer and a reputation for, frankly, the work that you should have done from the beginning anyhow.

Now, the important thing is going to be the handling of those findings. Here many companies go wrong. It is not good enough for your business to just fix the reported problems. Studies show that the developers never learn. That means your next release will have all those problems in the code again.

To do things right, you must set a special task to your development or testing – they must find ways to discover those problems during the development cycle. They must be able to discover the types of problems that were reported to you before they can be detected by the customer. Then, your code will improve and you will be able to lower the effort to fix for the next time.

And there you are, a quick and dirty fix, as promised. Just don’t fall for the fallacy of thinking that you have security now. You don’t. To get proper security into your products and life cycle will take a different order of effort.

Password recovery mechanisms – Part 3

Passwords remain the main means of authentication on the internet. People often forget their passwords and then they have to recover their access to the website services through some kind of mechanism. We try to make that so-called “password recovery” simple and automated, of course. There are several ways to do it, all of them but one are wrong. Let’s see how it is done.

If you did not read Part 1 – Secret questions and Part 2 – Secondary channel, I recommend you do so before reading on.

Part 3 – Example procedure: put it all together

Security - any lock matters as much as any other.

Let’s assume we are putting together a website and we will have passwords stored in a salted hash form and we identify the users with their e-mail address. I will describe what I think a good strategy for password recovery then is and you are welcome to comment and improve upon.

Since we have the users’ e-mail addresses, that is the natural secondary authentication channel. So if a user needs password recovery, we will use their e-mail to authenticate them. Here is how.

The user will come to a login page and clicks the link for “forgot password” or similar. They have to provide then an e-mail address. The form for e-mail address submission has to have means of countering automated exhaustive searches to both lower the load onto the server in case of an attack and provide some small level of discouragement against such attacks. There are two ways that come to mind: using a CAPTCHA and slowing down the form submission with a random large (an order of seconds) delay. Let’s not go into the holy war on CAPTCHA, you are welcome to use any other means you can think of and, please, suggest them so that others can benefit from your thoughts here. You should also provide an additional hidden field that will be automatically filled in by an automated form scanning robot, so you can detect that too and discard the request. Anyway, the important part is: slow down the potential attacker. The person going through recovery will not mind if it takes a while.

As the next step, we will look up the user e-mail address in the database, create a random token, mail it out and provide the feedback to the user. The feedback should be done in constant time, so that an attacker does not use your recovery mechanism to collect valid e-mail addresses from your website. The process thus should take the same time whether you found the user or not. This is difficult to get right and the best solution is to store the request for off-line processing and return immediately. Another way is to use the user names instead and look up the e-mail address but a user is more likely to know their own e-mail address than remember their user name, so there is a caveat. If you cannot (or would not) do off-line processing of requests, you should at least measure your server and try to get the timing similar with delays. The timing of the server can be measured fairly precisely and this is difficult to get right, especially under fluctuating load but you must give it a try. Still, it’s best if you keep the submitted information and trigger an off-line processing while reporting to user something along the lines of “if your e-mail is correct, you will receive an automated e-mail with instructions within an hour”. The feedback should never say whether the e-mail is correct or not.

Now we generate a long, random, cryptographically strong token. It must be cryptographically strong because the user may actually be an attacker and if he can guess how we generate tokens and can do the same, he will be able to reset passwords for arbitrary users. We generate the token, format it in a way that can be e-mailed (base64 encoding, hex, whatever) and store it in a database together with a timestamp and the origin (e-mail address). The same token is then e-mailed to the e-mail address of the user.

The user receives the token, comes to the website and goes to the form for token verification. Here he has to enter his e-mail address again, of course, the token, and the new password. In principle, some measure against the automated searches is in order here too, to lower the load on the server in case of an attack. The tokens are verified against our database and then the e-mail is checked too. If we see a token, we remove it from the database anyway, then we check if the e-mail matches and we continue only if it does. This way, tokens are single use: once we see a token, it is removed from the database and cannot be used again.

Tokens also expire. We must have a policy at our server that sets the expiration period. Let’s say, that is 24 hours. Before we do any look up in our token database, we perform a query that removes all tokens with a creation timestamp older than 24 hours ago. That way, any token that expires is gone from the database when we start looking.

Well, now, if the token matches and e-mail is correct, we can look up the user in our passwords database and update the password hash to the new value. Then, flush the authentication tokens and session identifiers for the user, forcing logout of all preexisting sessions. Simple.