I published a new cheat sheet, this one offering practical tips for finding and getting the right job in Information Technology, with a slant towards information security. You can view the contents on the web or print them as a 1-page PDF file.
This cheat sheet covers the following topics:
If you have comments or tips related to getting the right IT job, please leave a comment or drop me a note.
There is surprisingly little information online about creating good information security reports. You’ll easily find tips on performing web applications assessments, policy reviews and penetration tests, but it’s harder to locate advice regarding the best way to analyze the data and communicate the assessment’s findings.
To ameliorate this situation, I created a 1-page cheat sheet with tips for creating an information security assessment report. It includes some of the the assessment advice I’ve shared on this blog as well as additional tips, covering the following areas:
It’s available in HTML, PDF and Word formats, so you can print or customize the cheat sheet for your own needs. Thanks to Dave Shackleford and John Strand for their feedback on the draft of this cheat sheet.
The only thing I like better than reading cheat sheets is creating them. That’s why you’ll see a bunch of them on my website. I hope you find the new addition, which focuses on security assessment reports, useful.
"What is the worst information security advice you ever received?" I asked on Twitter. I’d like to highlight (paraphrase) some of the responses and also to point you to a listing of more bad infosec recommendations. This way you know what to advise your adversaries and, perhaps, what mistakes to avoid making yourself.
Just to clarify, the “advice” below is what the kind folks on Twitter received and shared with me. This is not the recommendations they themselves made.
More Bad Advice
Since I’ve heard (and maybe even given) my share of bad information security advice, I created some time ago a cheat sheet called How to Suck at Information Security. It lists 53 common infosec mistakes (‘cause listing 54 would give your adversaries too much ammunition).
Thanks to everyone who shared with me the bad advice they received! I got more responses than I could fit into one blog posting. If you’d like to contribute your tips, please leave a comment below.
Creating a structure for handling information security incidents is hard. On the one hand, there is the need to provide policies and procedures for people involved in the incident response (IR) process. On the other hand, documentation that’s too long and tedious is rarely read; moreover, it’s hard to anticipate every IR contingency when preparing the documents.
Here are a few tips for starting and formalizing a security incident response program.
The Hierarchy of Documents
Organizations differ in the criteria they use when designating a document a policy, procedure, guideline, and plan. Regardless of your nomenclature, you should have a hierarchy of documents:
Keep It Brief
Remember that no one has the time and patience to read wording policy documents filled with generalities. Keep your IR policies and procedures succinct and to the points. Use bullet points whenever possible.
Don’t worry about anticipating every possible contingency. Start with a set of documents that seems reasonable, so that you don’t dwell forever on getting them published. Then, amend them as you gain experience responding to incidents.
Avoid building upon IR document templates without customizing them for your specific needs, as such practices usually produce wordy texts filled with irrelevant concepts.
The Security Incident Cycle
Organizations also make the mistake on focusing on only one of several phases that comprise the security incident cycle. I discussed the big picture of the security incident cycle in an earlier article.
In addition to failing to devote proper attention to each phase of the security incident cycle, organizations often fail at knowing when and how to transition from one phase to another when dealing with an incident. The challenge is in part due to the differences in technologies and skill sets used in each phase, as well as in the different reporting structure of teams that need to collaborate when navigating the cycle.
References for Designing Your IR Program
The following papers and articles provide practical guidance for designing and implementing an incident response program:
In addition, I created a number of cheat sheets useful for incident response:
Sample Incident Response Plan Documents
If you’re wondering how other organizations document their IR programs, you’ll be surprised how much you’ll discover by Googling “incident response filetype:pdf”. Here are a few PDFs I found useful:
Keep in mind that even when you prepare for security incidents, you are likely to encounter a situation that catches you by surprise. I put together my thoughts on this topic in a presentation How to Respond to an Unexpected Security Incident (PDF) with full speaker notes.
Update: For a related post, see my article on The Critical Role of the Security Incident Response Coordinator.
Good IT professionals know technology. Great IT professionals also know communications. I’m not referring to TCP/IP protocols, but rather to the person’s ability to discuss IT concepts with both technologists and with non-techies. Strong communication skills are critical for IT professionals, yet they are rarely emphasized in IT training or education programs.
Here are my 10 tips for IT professionals who want to improve their communication skills:
For more communication tips, take a look at my one-page Troubleshooting Human Communications cheat sheet.
One of the cheat sheets I created offers tips for the design and review of a complex Internet application’s security architecture. It provides recommendations for considering the following security aspects of the application:
I created this security architecture cheat sheet (among others) because it’s easy to overlook a critical aspect of the application and its ecosystem when designing its security under time pressure. Specifically, I had the following three use-cases in mind for the Security Architecture cheat sheet:
Note that by “application” I mean a complex, multi-tier set of inter-dependent software and hardware components that process data and operate as part of the Internet’s ecosystem. In many cases, such applications are comprised of front-end web servers, application or middleware servers, databases, load balancers, firewalls, security monitoring systems and so on.
Have you found the Security Architecture cheat sheet helpful? I’d love to hear how you use it and whether you have recommendations for improving it.