Database and Webapp Security, part 1: Threat ModelBear Giles | December 11, 2011
This is the first of a series of discussions of database and webapp security loosely based on the quick reference page on my site. That page is becoming unwieldy and does not make it easy for readers to interact with me or others.
All security analysis must begin by examining the threat model. A threat model requires you to answer four questions:
- what I am trying to protect?
- from whom?
- for how long?
- and at what (net) cost?
What am I trying to protect?
This is the obvious place to start… and your first answer is probably wrong! What I mean by that is that you may answer “the database password” but that’s not quite right. What you’re actually want to protect is access to the database as that user – an attacker might be able to find a way into the databasewithout the password, e.g., SQL injection.
But wait, that’s not quite right either! Our real concern is preventing the attacker from using that access to cause damage, learn sensitive information, and so forth. At this point we should enumerate our actual concerns, e.g., our database may contain
- user content
- financial information
- user authentication and authorization
- static content
The way we access and use this information is varied
- user content – need ongoing read/write access
- financial information – need an oracle (for approval) and can leave details to fulfillment process
- user authentication and authorization – need an oracle (for approval and authorizations) when a user logs in but never afterwards (oracle)
- logs – need ongoing append-only access (oracle)
- static content – need read-only access on startup (oracle)
(All of the access is modulo the need for maintenance.)
An oracle is a standalone method that takes (optional) values and returns either true or false. A bit more generally it can return any self-contained, immutable object. A good implementation choice for an oracle is a stored procedure in the database, a better choice would be a REST call to another webapp using an independent database.
Two examples of oracles:
User authentication: Use an oracle that takes a username and password and returns a boolean value indicating whether it was valid or not. (Alternative: return full authn/authz structure upon success.) The non-oracle approach is for the application to do a query on the user and password tables and compare the passwords itself.
Credit card authentication: Use an oracle that takes the credit card information and amount of purchase and returns either a confirmation number or an error indication. The application can rely on the oracle keeping a copy of previously provided values (but not the CVV!) so the user doesn’t have to fill out the same information every time. . The non-oracle approach is for the application to bundle the information itself.
The point I’m making here is that deciding what needs to be protected is an architectural question and a bit of foresight can have a dramatic impact on threat model. You want as little exposure to untrusted users (e.g., the webapp) as possible and small changes can make big differences.
Last but not least there is one other thing that the should be protected: your reputation. Not the company’s – the developer’s. What do you say when you get a phone call from the president of the company demanding to know why the company will be the lead story on the nightly news? You can’t protect against all attacks but you don’t want to be left speechless when someone demands to know why you didn’t take basic steps to protect the system.
Okay, I kid. But there’s a far broader list than you first think.
- fumble-finged employees. We’ve all done this. They already have legitimate access.
- disgruntled employees, especially the soon-to-be-former employees. They already have legitimate access and motivation.
- script kiddies. We tend to think of them as unsophisticated but they may be running cracking tools written by experts. They’ll probably move on to easier targets if your site is reasonably secure.
- advanced persistent threats (ATP). These are the people who have a strong motivation and strong technical skills. Assume they will get in.
This list is far from exhaustive and listing additional ‘potentialattackers’ is left as an exercise for the reader.
For how long?
At the risk of being obvious there’s three broad categories
- Information or access that must be protected until a relatively soon specific date and is then open knowledge, e.g., corporate financial reports.
- Information or access that has declining value over time.
- Information or access that must be protected forever, e.g., confidential legal and medical documents.
“Cost” is a flexible concept since there are so many indirect and inferred costs. E.g., what’s the cost in making it harder for people to do their work… or is it cheaper since the system won’t be down for days after a breach? What’s the cost of people leaving the site in frustration vs. the benefits of people not leaving the site en masse after a breach at your site made the national news?
The bottom line is that this is ultimately a non-technical question. All you can do is identify the direct and indirect concerns and let the powers-that-be make the final determination.
Putting it together
The bottom line is that the threat model is ultimately a business decision. We can provide analysis and recommendations but the ultimate decision has to come from above.
That said there are many things we can do on our own initiative. This series will address some of them.