securing applications: risk assessment?

in reviewing some information here and googling, it appears that "step 0" in securing our applications, would be to perform a risk assessment. there, of course seems to be no shortage on information on this topic. but i did have two questions:

1) is risk assessment "step 0" in looking to secure, nay protect our applications, or is there a step before this?

2) beside the links below that i will list, has anyone come across a proven way to better protect their apps?

site risk assessment - i thought some good general steps, page 3 has the "5 Steps": http://www.hse.gov.uk/pubns/indg163.pdf

Network Computing article on subject: http://www.networkcomputing.com/1121/1121f3.html

U.S. GAC technical paper, page 7 has a good map i think: http://www.gao.gov/special.pubs/ai00033.pdf

any others or advice on this topic? as we do not currently have anything in place, i believe we should start off with basics of looking at risk and start reviewing our application and project charter against that. as you may be able to ascertain, we will be retrofitting security into our apps. tia!

Guan-Di

The first thing you need to do is more clearly define your questions and objectives.

1. You use the expression "applications". This generally means software such as accounting packages, office suites, web browsers and so on..........................I don't think that is what you really mean, unless you are a software developer; in which case it is an issue.

2. Start by considering your topography. LAN, WAN, INTERNET, Stand Alone. Desktops, servers, routers, switches..............in other words the geography of that which you are dealing with. You must agree up front as to what is "in" and what is "out".

3. From the above look at the various elements and ask your self: Where are they?, what do they do?, who accesses them?, what do they connect to?

4. Look at your databases and their content..........particularly your legal obligations in respect of that content. Also backup routines, remote backups and legal retention periods.

5. Consider physical as well as electronic/systems security. Without adequate physical security you are pretty much wasting your time.

6. Consider disaster recovery, remembering that not all threats are from spotty little scumbags hunched in basements.

7. Consider authority levels, checks and balances and audit procedures. You need a policy before you can even think about risks ;)

8. You will need:

[a] A good management/financial accountant
[b] Access to a competent source of corporate legal advice
[c] A red hot project manager...........certainly not one for the mailboy ;)

Apart from all that and about three pages more, it is pretty simple................allow 9 months to 1 year...............you have to get it signed off?

The point of a risk assessment is basically to determine what you lose if X happens.

You'll find a numeric system quite useful for this. For example:-

If database A on it's primary server loses all it's data the damage = 10/10... But, you have an efficient, monitored and regularly tested backup system operating on database A, the damage is now only = 5/10 because that database must be online 24/7.

Those are arbitrary numbers - your risk assessment team need to come up with your own numbering system if you go this route, it doesn't have to be out of ten - you may chose a 4 step system. You also would determine what number indicates "acceptable risk"... you may chose 6/10 to be the point above which the risk to that system is unaceptable.

Once you have determined these things you need to do as Nihil says. You need to know your systems inside out and backwards and how they interact. It's the "silly" things you are looking for. Example: (a silly one). Application A must be run as root/administrator and is accessible by the majority of users in the company. Compromise of the data within application A is assessed at a zero in terms of risk - it's the internal phone directory let's say... But it is housed on the same server as your primary financial application compromise or loss of that data would be assessed as a 10/10... Clearly that adds a lot to the risk associated with Application A because, were it to be compromised then the attacker might have root access to the server and thus the financial application. It's those kind of relationships you _must_ find prior to beginning the actual assessment of risk.

Risk Analysis Basics:

1) What can happen?
2) How often can it happen?
3) How bad would it be?
4) How accurate are my answers to the above three?

Approaches to risk assessment:
1) Qualitative, which focuses on subjective losses such as share holder perception, etc.
2) Quantitative, which focuses on measures based typically on dollar value.
The math for this is SLE = EF x AV (single loss expectancy = exposure factor x asset value)
ALE = SLE x ARO (annual loss expectancy = single loss expectancy x annual rate of occurance)

While Nihil gave you plenty of things to consider when doing an enterprise wide assessment, I read your question as specific to applications. If you attempt to do all of the things above, you'll be working on your assessment for years and may be outside the scope of the true task.

Also, if you're simply looking to do the RA on applications, be sure that you define the scope of the assessment before you do anything else, get MOUs in place by all involved so everyone understands the scope (this is part of the procedure as well as a CYA move), and finally, hand over your assessment to management and let them select, transfer, accept or avoid the risk.

Hope I covered what you're looking for. If not, fire some more questions.

--TH13

Hi Tiger~ happy Easter mate!

Yes, I read Guan-Di 's question as a sort of "pre-project planning" exercise, as he did mention "Step 0".

The way I see things are that you start will an overall enterprise/institution security model. Then you sub-divide it into more manageable sub-projects and dish them out.

I am not sure if he has one of these sub-projects in mind or not, or if he even has what his terms of reference/scope are.

I am awaiting some more feedback and detail.

Wot!...............I have been tricked, and lured into posting into a security related thread :eek:

Joking apart, Guan-Di , this is an interesting topic..................please keep it going.

:)

my apologies for not replying earlier today; i tend to get caught up in my 'real' job of support, however i do sincerely appreciate all of the great responses.

some information, again my apologies, as my brain is starting to have an unscheduled shutdown:

0. first me. i'm not a developer, yet, i support the productive apps, however, i have been given an opportunity to learn more about security and present ideas to the development team and their management to basically retrofit their apps with security. nihil and thehorse13 , you are correct, i have, hopefully, a limited scope; that being the scope of my effort is to lockdown our set of assigned applications, and work with IT to better protect, or at least ask and see what security measures are in place for the infrastructure. i know that can become nasty, but i am just asking questions and looking or trying to be pushy; that doesn't get me anywhere. this whole effort is in response to an internal check by our IT department anyway and we just 'found out' that we may not be in compliance with our company's standards for application development; which i thought odd for a set of applications being in production already, but then again, i am a noob to security, so i am observing and learning at this point.

i have two of the developers and an admin guiding me with some much needed ojt to assist my learning. i am also looking to learn about our network topology; that part i am very weak in, i know it, and so do they. nihil - good point - i need to have them learn me about what areas of our network we actually touch, cross-dependencies and the like, at least to make sure we have at least thought about it.


1. we have a mixed environment. by that i mean that our applications reside on a mainframe, which is fairly "locked down" i am told, our databases reside on open systems; both Windows and SuSE Linux... and we have a Web presence; i don't support that part yet, but am learning it.

2. thehorse13 , you're right, i need to explore more with management and get their requirements, so far this is not a formal project, however i think i need to request it to be so asap; will do that monday, and i don't care to be the project lead at this point, as i think it would take away from my learning about the IT facets, however, i'll discuss it, thank you!

also please, but what does "MOU" mean? tia sir, my brain is almost completely shutdown now, and i don't know if it will reboot over the weekend. i "think" management knows they are in a risky situation, but they don't believe IT infrastructure that much, even though a few of the managers came from that area; i'm not touching that topic, however as part of the request to make this effort a project, we will get down their requirements, hopefully implicit as well as explicit and strictly define the scope.

3. tigershark and thehorse13 , as i work with management to frame the scope of this effort, excuse me, project i will mention your points as well and see what they have to say, to me after reading your points, it makes sense to do, i and we just needed to have the light turned on for us.

thanks to you all for taking the time to guide me on this, i will share this information with the people in the "real world" i am working with and also tell them what a tremendous help everyone has been; thanks! i look forward to your responses, whenever you get the chance to post them! also, please let me know of questions you may have of me. to those who celebrate it, [gloworange]HAPPY[/gloworange] [glowpurple]EASTER![/glowpurple] :D

Quote:

---

also please, but what does "MOU" mean? tia sir,

---

Memo of understanding

--TH13

Hi, Guan-Di and a Happy Easter to you.

I believe that I now understand your situation, in that you are supporting "front office" applications.............the Ledgers, inventory, sales order processing, logistics, office productivity..............that sort of thing?

Please correct me if I am wrong, but my impression is that you deal with the end user systems, the various departmental/functional managers and their staff. That puts you in the "Business Analyst/Support" category over here ;)

OK, to get started, can you list the functional areas and applications/systems that you will be responsible for?

You MUST get this recognised as a project as it will require a fair amount of time and resource......................in particularly that of other departments, who may not see things as we do?

:)

Hi there Guan-Di
This isn't a magic fix for your problem, but it might help you along. The following are some links to resources for risk management. I have done some work with risk management in my job and the best first step you can take is to adopt a methodology that fits your business. The previous responses have outlined the basics of a number of different approaches. Which one is correct is determined by yourself and your management based upon your specific business requirements.

ACSI33, Chapter 4 Risk Management
http://www.dsd.gov.au/library/infosec/acsi33.html

AS/NZS 4360:1999 : Risk management
HB 231:2004 - Information Security Risk Management Guidelines
http://www.standards.com.au/
These ones are available at the above site for a price. Bear in mind, these are Australian Standards, you would be best to check and see if equivalent docs exist for your country

US Rainbow Series Library of Computer Security Standards
www.radium.ncsc.mil/tpep/library/rainbow/
These are getting a little on the old side and may not be entirely relevant. I honestly can't recommend these never having really looked into them too deeply. They are (or were) considered a good standard so they may be useful to you.


Hope this helps

Regards

TG

Latching on to TechGrunt's post, please see the NIST 800 series of documents. These are used more often than the rainbow series (TCSEC, TNI, etc.).

I personally base all of my policies off the NIST 800 series.

--TH13