Posts tagged cheat sheet

Tips for Getting the Right IT Job - New Cheat Sheet

image

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:

  • What to do before you start looking for a job
  • How to use social networking as an ongoing part of your career
  • Steps towards finding the IT position worth pursuing
  • Advice on crafting and polishing your resume
  • Tips for negotiating a favorable compensation package

If you have comments or tips related to getting the right IT job, please leave a comment or drop me a note.

— Lenny Zeltser

Cheat Sheet for Creating Security Assessment Reports

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:

  • General Approach to Creating the Report
  • Analysis of the Security Assessment Data
  • Assessment Methodology Documentation
  • Scope of the Security Assessment
  • Documenting Conclusions
  • Qualities of a Good Assessment Report

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.

— Lenny Zeltser

The Worst Information Security Advice Ever

“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.

Password Security

  • ebcovert3: Use a password that’s 7 characters long
  • stromsjo: “Your password may not exceed six characters in length.”
  • CyberArmory: Use this password… It was randomly generated and is secure (by the IT staff)

Network Security

  • EthernetGuru: “No need to change the default logins, we have a firewall and nonstandard ports in use.”
  • rickflores_: We have a firewall, so our web apps are safe, and we do not need a pen test done.
  • chrisomar: No need to protect the database servers—they are behind two firewalls.
  • _Dark_Knight_: If I allow a connection out I have 2 explicitly add a rule to fw to allow traffic back in on said port.
  • mborbanovo: “Use NAT, it will hide your network from intruders.”
  • marinusva: Don’t worry. It’s the trusted internal network.

Security Practices

  • NightShade003: “Deploy it to production first, we don’t have time to test in QA”
  • hybridrisk: “We don’t need policy….we have all been working together for 20 years”
  • rogue_analyst: “If you don’t log anything then it can’t be subpoenaed.”

Malware Defense

  • heidishey:Why don’t you plug this mysterious USB key into your roommate’s computer?
  • 4n6woman: Don’t worry about malware if you have a Mac.
  • Marts_McFly: Use anti-virus to protect your WiFi access point from intruders.

Other Areas

  • vmforno: With this “security tool” you don’t need nothing more.
  • voodookid: “It is okay the web server runs as root, it is only going to be on a local network.”
  • angelofsecurity: “Don’t worry, no one will ever target us.”

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.

— Lenny Zeltser

Tips for Starting a Security Incident Response Program

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:

  • A brief high-level document that describes the goal of the IR program. The level of detail should be appropriate for a non-technological executive manager. (I think of this as a policy.)
  • One or more longer documents that include details regarding the approach to IR that should be exercised by the organization. The audience for this documentation should be technical managers and other individuals implementing the IR program. (I think of this as procedures, though some might call it policies.)
  • Detailed technical documents for the various situations that incident responders might find themselves in. The audience for this is technical staff that is responsible for taking IR steps. (I think of this as guidelines, cheat sheets and checklists.)

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.

— Lenny Zeltser

Strong Communication Skills: 10 Tips for IT Professionals

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:

  • Empathy is key. What is important to your listener? Frame the conversation from his or her perspective.
  • Watch out for tech jargon. Terms and acronyms that are second-nature to you, might be foreign to the other person.
  • Be careful not to sound superior when discussing topics in which you think you’re better informed.
  • If one or two email messages don’t explain your perspective, switch to phone or in-person communications.
  • Use email to prepare the person for a meeting or a phone conversation.
  • Don’t respond in the heat of the moment. Let your emotions cool off before hitting the Send button or picking up the phone.
  • Find the best timing for the conversation: some people are grumpy in the mornings, sleepy after lunch and in a hurry at 5pm.
  • If the person doesn’t respond to your first email or voice message, don’t take it personally. Follow up.
  • Conclude the conversation by agreeing on the next steps, who will do what and what the due dates are.
  • Be brief.

For more communication tips, take a look at my one-page Troubleshooting Human Communications cheat sheet.

— Lenny Zeltser

How to Use the Security Architecture Cheat Sheet for Internet Applications

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:

  • Business requirements: You need to understand the purpose of the application, including what it does and how it makes money, to offer security recommendations.
  • Infrastructure requirements: You need to understand network and operating system requirements of the application to create a comprehensive security design.
  • Application requirements: You need to pay attention to application-level aspects of the security architecture, including access requirements and data flows.
  • Security program requirements: You need to incorporate on-going procedural tasks into the security design to make sure the application’s security is maintained on on-going basis.

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:

  • You can use it when examining an existing application as part of a security assessment
  • You can use it when initially designing an application before starting to implement it
  • You can use it as a reference for on-going maintenance of an existing application

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.

In addition to being available in an HTML format, the cheat sheet is also available as a printable two-page PDF file and as an editable Microsoft Word document.

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.

— Lenny Zeltser