I just read Roger Grimes InfoWorld Security Advisor latest Blog entry and couldn't agree more to the "5 big security mistakes you're probably making" article. Here are a few more and expand on his 5.
1. Security mistake No. 1: Assuming that patching is good enough
2. Security mistake No. 2: Failing to understand what apps are running
3. Security mistake No. 3: Overlooking the anomalies
4. Security mistake No. 4: Neglecting to ride herd on password policy
5. Security mistake No. 5: Failing to educate users about the latest threats
I like where he went with this thread, many organizations still miss the basics, like basic training in the military or practice in sports, the basics must still be done, done well and done well always!
To expand on Roger's post...
1. Patching - Do you really even know what is installed and needs patching ? Start with priorities, if it's Internet facing or a user has Internet access, make these apps a priority to patch. More importantly, make an approved list of software so you can track what you have so you know what to patch, assuming you get or follow alerts and notifications. Can you say 'Google Alerts'...
2. What Apps are running - In the old days we called this baselining. When you build a system, dump what users and applications, services, daemons are on the system so you can compare it to the baseline list when you troubleshoot. Also keep track of which services, apps and daemons need credentials and where these creds are stored so #4 can be maintained. If your system is already deployed, then start with that and identify all the components and get a build document created. Then you have a chance to do #1. Same priority applies, Internet facing systems first and systems with users that access the Internet, high risk, etc.
3. Anomalies - You may be lean and mean in staffing and unless you have a good forensic team, re-imaging systems with anomalies might be your best bet. You WILL get compromised at some point so how fast can you recover, re-image or revert a VM snapshot is key.
4. Passwords - If you don't know where all you user repositories are, you can't enforce policy. Local accounts, services, daemons, apps that attach to other systems, etc. Learn where you have accounts, document them in a matrix and make those passwords long and complex if rotation is not an option or the risk is low and monitor for misuse of these service type accts and please disable login if all they need is to authenticate. And NEVER use the default accounts as these make great nefarious activity detectors.
5. Regular and ongoing education or exposure to real threats that users face needs to be enforced or reminded, often. When you get a good phishing email, print and post it in a public area, rotate them quarterly and fill up a 2x3 Poster Board with real examples. Discuss using Browser plug-ins to help protect the user from themselves. Remind them how Microsoft says being an Admin is bad by posting the studies everyone puts out these days. This is real world info to remind people the Internet IS a scary thing to use with protection. Don't forget to post Brian Krebs research on ATM skimmers and Credit Card fraud with images of the units and screen shots... These are powerful educators.
Now for my $.02 worth...
6. If you couldn't guess, administrative access is my next one. Remove it and do everything you can to get your users into the Standard User model with VM's to run admin tasks or do development, or issue separate systems on a test/lab/Dev network that does not allow email clients or open surfing.
7. Implement re-imaging of user systems on a malware alert or every 2 years. This will accomplish a couple things, one, it will curb user behavior of visiting sites with malware, they know where they were when the AV triggered. Two, reduce the applications that developers and users install at any given time that they 'think' they need (see #6). Reduce your installed application list reduces patching requirements and software inventory lists. And we all know re-imaging is the only real way to clean an infected system. Create a process of when to re-image user systems. Applies to servers too, but only ones that have VM snapshots, but develop DR for the others too. Remember.. You WILL get Pwned at some point.
8. Don't install Java, Adobe, browsers or mail clients on servers, if you must, use plug-ins and only allow security minded admins to use the browser to update the system. NO open surfing on servers, there is no reason, instead surf on a workstation, download what you need, expand the archive so AV can do its thing and copy over to the server. Yeah I know..
9. Apply the same internal processes to cloud apps and servers. Studies have shown that the processes we follow for internal firewalls for example, are not applied to cloud firewalls or security policies leaving cloud systems open to hacking or exploitation attempts. Lack of process I feel is the #1 Cloud risk.
10. Prepare for the BIG ONE, it will happen to you at some point, so how fast can you recover? Or will you be like Stratfor, Sony, Zappos, Gawker, Amazon and Azure and suffer untold reputational damage. Prepare to recover as a part of BCP and DR and yes... Incident Response...DR/BCP lives!
11. And last but not least.. ENCRYPT your user credentials, laptops, desktops and removable drives so you don't end up like the people mentioned in #10.
Roger Grimes Blog Post
#InfoSec #RogerGrimes
