Moving blog

| No Comments

In order to downsize my Internet plumbing, I am moving my blog to All updates will be made over there, as of now. All content has been migrated over and I'll be updating the apache config to automatically redirect to the new location. I'll try to fix the RSS feeds so that the move is transparent. All bookmarked links will break.

The new blog can be found at

Apologies for the inconvenience.

Teaching again

| No Comments

I have started preparing my introductory computer security course for next semester. The course is geared towards junior and senior undergraduate computer science and information systems students. As much as possible, I like to bring in writing assignments (human language, not computer code), and hands-on assignments. 

This year, I feel that it is time to shake stuff up a bit and change a bunch of topics around. So, I've decided to ask for some community feedback. There are 15 weeks in a semester. Each week, I have 2.5 hours of instructional time, and assignments can go in addition to that. My expectation is that all student spend 4-5 hrs per week on the material. 

Here are some of the topics that I want to include. Note that this is just a simple bullet list. What do you think? Should I add/remove topics? How would you order them in time? What kind of assignments and what kind of reading materials would you recommend?

Topics to be covered
  1. Introduction to describe what we are protecting, who is attacking and how we are being  attacked
    1. Defender methodology (defense in depth, cia, pirl, business continuity)
    2. Attacker methodology
    3. Risk and stuff
  2. Ethics and law
    1. Ethics
    2. Codes of Ethics
    3. Relevant Law (Federal and State)
    4. Relevant Law Enforcement Agencies
    5. Investigations
    6. Evidence
  3. Authentication
    1. Identification plus verification
    2. Multi factor authentication (aka: why passwords suck)
    3. Password attacks
    4. Social engineering
    5. Stupidity (default passwords, silly reset mechanisms, etc)
  4. Access control
    1. Some boring theory about models (DAC, MAC, RBAC)
    2. Examples of access control bypass
  5. Cryptography
    1.  Confidentiality
    2. Authenticity
    3. Non-repudiation
    4. Hashing
    5. PKI vs web of trust
    6. Block ciphers vs. stream ciphers
    7. Symmetric vs. Asymmetric crypto
    8. SSL
    9. SSH (hands-on) including hardening
    10. WEP/WPA
  6. Open source intelligence gathering
    1. Domain and IP registration process
    2. Whois
    3. DNS
    4. Web sites
    5. Job advertisements
  7. Networking
    1. TCP/IP
    2. Layer 2 stuff
    3. Equipment (Firewall, Router, Switch, Hub)
    4. Nmap
    5. Tcpdump
    6. Vulnerability scanning
  8. Common causes of exploitation
    1. Bad software
    2. Bad configuration
    3. Bad people
  9. Web application attacks
    1. SQL injection
    2. XSS
    3. CSRF
    4. OWASP top-20
  10. Endpoint attacks
    1. OS exploitation
    2. Application exploitation
    3. Vulnerability management 
    4. Metasploit Framework
    5. Antivirus
  11. Mobile stuff
    1. OWASP mobile project
  12. Enterprise security
    1. IDS / IPS
    2. Log management and SIEM
    3. DLP (on-premise and in-cloud)
    4. NAC
    5. Vulnerability management / patch management

Removed from the course
- forensics 
- building buffer overflows

Source: stock.xchng
More and more I get the feeling of not being taken seriously by my vendors. It appears that it is time for a few reality checks. 

Vendors: Not a single one of you provides such a unique and special product that there are no alternatives. 

Between reduced customer services, botched contract renewals, insane price increases and now the next one, trying to strong-arm me into re-negotiation my contract well before it expires in an attempt to lock me in for another 3 years. 

Is it really that hard to understand that the relationship between a client and a vendor is based primarily on trust? 

Sure, you offer a good product, and of course the price that I negotiated with you is making you take a loss on the deal, but do you really not realize that when you damage the trust that I have in you, I have pretty much no other avenue that not continuing our relationship?

In the last month, this happened to me twice. Two vendors have been told that I will not be renewing my contract; both of them acted as if they were surprised. Initially, I started to believe that my expectations are too high, until I realized that they work for me, and I do not work for them. No vendor can tell me what is best for my organization, or where I need to focus my resources. That value-decision is mine to make, and I will make it.

Sure, "forklifting" an existing solution out to replace it with another one can be expensive, but it does not have to be with proper leadership. It is time to realize that clients make decisions primarily based on value that they perceive, and a real prerequisite for me to perceive value is that I need to trust you.

And no, trust is not obtained by buying me drinks at Defcon or by serving me fantastic steak dinners at BlackHat. Trust is obtained by showing me respect, by being predictable, and not by blindsiding me with stupid requests and unwarranted changes for which I have not asked.

A few important lessons to take away from this:
  • Architecture trumps technology each and every time. Never build a situation where you end up with a technology lock-in.
  • Be open and receptive to your vendors, but do not let them give you the run-around
  • Always have a plan B in place for every technology that you use
  • Do not be afraid to use plan B
  • If you have the luxury of being able to do so, focus on VALUE rather than on COST

Product acquisitions

| No Comments
handcuffs (300x179).jpg
Source: stock.xchng

As with many good products, my SIEM vendor got acquired earlier this year. Unfortunately, as it happens all too often when good products get acquired, customer support has been declining, prices are increasing, and as of yesterday, I am locked out of my product altogether. My license expired and it was not renewed in time (despite several requests directed at the vendor to invoice me)! One day after the license lapsed, a critical service on the box died and, since I do not have a valid license, tech support refuses to even take my call or escalate it to a manager. My VAR has as of yet been unable to resolve the situation.

There are two major lessons in this. 

1. If one of your vendors is acquired, and the product that you purchased from them is more than non-essential, look for alternatives immediately. Start talking to their competition, get quotes, find peers who use similar techniques and learn from them what is good and what is bad, and draft a high-level migration plan to move away from your current supplier. If the acquisition turns out a good thing, you did not lose anything, but you have a better understanding of the vendor landscape. If the acquisition turns out to be a bad thing, you are ready to move and you have demonstrated proactive leadership.

2. As a good practice, you should always have a plan B, regardless of a (pending) acquisition. In my case, I had a fall-back plan and I have activated that. Consequently, there has not been a serious interruption, and business is continuing as normal, albeit severely less efficient.

Latest Tweet