Threat model document

Question

I am in the process of writing a threat model document for one of the applications which I am hosting.Its a Apache website which allows users to login, create their widgets by adding some best selling products etc. Can someone give me pointers on how to start with this ?

Frontend uses javascript + perl, backend is cpp. We do accept sensitive information from the user like his name, SSN etc and we do a store session-id

• What are some of the ways I can identify security holes in my application ? How should I start with this ?
• What are some of the areas which should be part of the document ?
• what are some of the threats like DoS etc. which I should read about ?

Answer 1

For your methodology of Threat Modeling, check out MyAppSecurity's ThreatModeler. Pretty easy to visualize your application from a high level architecture diagram and identify potential threats as well as find remediating controls in terms of secure code and security controls.

Cheers

Answer 2

Disclaimer:

I am neither a security expert, nor a compliance expert, nor a lawyer. Do not take this advice at face value. You should seek expert advice when dealing with confidential information.

Compliance and regulations.

I really cannot sum it up for you, please have a read: http://en.wikipedia.org/wiki/Information_privacy_law

United States : FISMA and FIPS

( Including but not limited to... )

There are standards and laws http://en.wikipedia.org/wiki/Federal_Information_Security_Management_Act_of_2002 http://en.wikipedia.org/wiki/Federal_Information_Processing_Standards

FIPS 199: http://csrc.nist.gov/publications/fips/fips199/FIPS-PUB-199-final.pdf

FIPS 200: http://csrc.nist.gov/publications/fips/fips200/FIPS-200-final-march.pdf

Back to the question...

We do accept sensitive information from the user like his name, SSN etc

FIPS 199 and 200 will give you good starting points for evaluating what needs to be done.

What are some of the ways I can identify security holes in my application?

• Pay experts for reviewing your strategy.
• Pay experts to do pen-testing
• Pay hackers for responsible disclosure.
• Look at the Common Vulnerabilities and Exposures (CVE) database: https://cve.mitre.org/
• Look at the exploit database: http://www.exploit-db.com/

e.g. for perl... https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=perl

How should I start with this ?

Start with this definition of Information Governance (IG): http://searchcompliance.techtarget.com/definition/information-governance

Assess how the info is used and where.

Write penetration tests for your own software using relevant info from the CVE / exploit database.

What are some of the areas which should be part of the document ?

I find that using a system architecture diagram is helpful in identifying what parts to test independently and isolate; and which boundaries to secure.

If you have looked and the previous section, you should have a good idea about what you could put in the document.

what are some of the threats like DoS etc. which I should read about ?

These are listed in the CVE / Exploit databases.

Answer 3

Ask as many people as you can find to think about ways to break the system. It's very likely that they'll think of things you won't. Thinking outside the box is crucial.

A proper threat tree analysis starts with a series of bad outcomes ("sensitive data leaked", "servers hijacked to host malware/send spam/be part of botnet/whatever", "company defrauded by use of stolen credit card details", and you can hopefully think of more) and works backwards: what would be necessary for that to happen? Often you'll find that each bad outcome will have several required enabling events - a causal chain - and by comparing them you can identify weak spots and plan your defence in depth.

Answer 4

This might not help in building the threat model document, but the OWASP howto might help you in validating the design of the application against the industry best-practice.

Answer 5

I'm no expert in security, but here are my two cents.

1) You can safely regard javascript as completely insecure, as you don't really control its execution.

2) So, the perl part is the first line of defence. Read perldoc perlsec for starter.

Perl code containing eval, backticks, system, and open should be inspected (always use tree-argument open, just to be sure).

Also code that lacks strict/warnings should be reviewed and, ideally, rewritten.

Any input that is not checked thoroughly for validity is suspicious. Of course, no unprocessed input (except for user's files that are only stored by the system) should ever reach your back-end.

3) From my recent experience:

• we had JSON deserialization based on feeding the input to a regexp and then eval'ing it. I've managed to pass perl code through. FAIL.

• we had a chunk of code that was obscure, strictless, lacked any comments, and relied on certain behaviour of external programs that forced us to use outdated ssh version. FAIL. (I admit to failing to rewrite it).

• we had open (FD, "$file");. While leading /'s and ..'s were removed from $file, apparently it wasn't checked for the pipe symbol (|). A carefully crafted command could be supplied instead of a file name. FAIL. Always use three-argument open. Same goes for system/exec: only @array variant is OK, don't rely on stupid ls '$file'.

I would appreciate additions and/or corrections from other people.