Re: Security Basics Exercise - How do you know?

[krymson () gmail com]

If this is what you do (not sure if this was you asking about your situation or just posting a hypothetical exercise 
for us to muse, so I'll just assume the former), then I'd say you're ahead of the game compared to most! :)

Here are some other suggestions I'd throw around, although we're starting to get into less high-level stuff and things 
that you likely do but just didn't mention. By the way, ask your CTO if he/she knows their car will run today without 
issues, and how they know that for sure. Life has few guarantees. :)

- check those OS event logs for unexplained errors

- check application logs for possibly successful attacks (web logs that show bad requests returning 200!)

- throw in some integrity software like tripwire on important files to check for changes. Disk consumption is a big red 
flag, but a replacement of an exe is more subtle.

- if you use NTFS on your disks, do a regular ADS scan for hidden files. This would be rare and the scans are still 
slow, but it's just another thing to check off when done.

- I like full network captures on the server interfaces, especially if you have someone who has an interest in 
analyzing such data. This overlaps a lot with firewall and IPS coverage, but may reveal some patterns if something bad 
is happening, like lots of outgoing SSL at night or something. I think just investigating the largest endpoint 
connections would suffice. What are your servers communicating with the most, and is that legit?

- verify the physical security of the servers, or at least the auditing. Locked doors, account for all the keys, camera 
to record who does what work on them and when, etc. Additionally, does anyone check for odd USB fobs on the back? :) 
Again, rare, but if a CTO really wants to be sure, these checks should be done.

- all system downtimes, as indicated by monitoring alerts, have been explained or at least rigorously investigated

- you may cover this already, but recheck software inventory on the servers and make sure those are patched as well. 
For instance a webserver using an old php forum version still has vulns that possibly a vuln scanner won't pick up.

Yeah, I'm reaching a bit, but I'll restate that your initial list is pretty nice already!




<- snip ->
Here's the what-if scenario:

Your CTO calls your various IT groups together and poses the following question:

"Do we know, as of right now, whether or not one of our public-facing
systems has been compromised?"

The fact is, and there is no way to answer this question with 100%
certainty (at least I don't believe so). However, we should be able to
answer this way:

"We have as high a confidence-level as we can that no system has been
breached because when we look at the various systems, we:

- do not see any unauthorized user IDs (or, no unauthorized ID's have
been created within the last x hours/days/weeks)
- do not see any unexpected services running
- show the systems are fully patched
- show the systems are 100% compliant with our standard build
- show that there are no known vulnerabilities presently unaddressed
- have not seen any unauthorized root user activity
- do not see any unusual activity in our host-based IPS
- have not received any alerts from the network-based IPS
- see that disk space usage has not changed significantly
- so not see any unusual traffic on the firewall (such as denies,
numerous abnormal connection-types, etc)
- checked the system with AV and anti-spyware and it came back clean

....."

> From a high-level, what else would you have in place to prove that
your public systems are/were not breached?

- Ryan