Wednesday, June 18, 2014

Tips for getting started in information security

Note: this is a repost from a piece I wrote in October 2008. Most of it still seems very relevant.

I regularly get questions of students who are asking what they need to do to get started in the information security field. Unfortunately, I cannot give a straight unambiguous answer to that. What I can do is start a thought process for that student. In the end, they will have to do the work.

Become experienced
Get a job that sounds like it is relevant to security. It does not actually have to be dead-on, but when a potential employer reads your resume, she must feel some sort of connect. Unfortunately, most security jobs ask for experience, so that is exactly what you need to get.

Most likely, the easiest way to do so is to find a job for a large consultancy organization and make it clear to them that you are willing to work hard, travel when necessary, and add value to their organization. At the same time, don't let your employer ever doubt that you are going to become an information security specialist.

Information security professionals are service providers, and you need to figure out if you want to become a consultant that comes in to do a job, or if you want to work for the organization that uses your services. Make up your mind if you want to become a product specialist. Early in your career, consulting is not a bad way to go, since that will expose you to different industries, different problems and different working cultures.

Deciding if you want to work in a specific industry, or in a particular geographic area is also part of making the focus decisions. I know people who decided very early on that they wanted to work for a specific organization and they had their career plan centered around that goal. The same is true for geographical areas. If you decide that you want to work in the New York City, you will probably end up in the financial services industry or in fashion. If you are on Long Island, start learning about medical services. Other areas have similar industry focuses.

Think hard about the area in which you want to specialize and work towards that. Depending on the direction in which you want to move, you will need to spend just about every waking hour doing "stuff" with security.

If you choose your direction to be penetration testing, find a pentesting job. When you come home, start doing stuff in your own lab. If you want to become an incident responder, look in that area and start dabbling with forensics-type stuff on your own time. If you want to become an information security manager, try to get some leadership experience. If you want to become an application security specialist, start looking at code.

There is much discussion surrounding the actual value of a security certification, but the basic fact is that employers will look for something that can distinguish you from the rest. Not having a certification is definitely a distinguishing factor, but it may not be what you want.

When choosing your certifications, keep your specialization goals in mind. It is useless (and may even work against you) to pursue vendor-specific certifications if you want to do something with a broader scope. The opposite is also true-- striving to pursue a general certification when you want to be a niche specialist is also pointless.

Make yourself visible: become a member of security organizations and go to chapter meetings. Attend as many events as you can, even if they are not in your focus area. At worst, you will spend an afternoon thinking about why the topic is not relevant to you (also valuable), and at best you meet your next employer.

If there are no chapters, start one. If you can afford it, begin visiting security conventions and conferences, reading (and comment on) blogs, maybe even start your own blog, join dedicated chat rooms and online forums, jump on twitter, linkedin, etc. Set up your own web site; don't be afraid to oversell yourself, but never lie. As an information security professional, your personal reputation and credibility is everything. The information security field is young, highly dynamic and the good people in the field form a close community. Associate with the right people.

Finally, come up with a career plan. That plan will be perfect nor complete when you make it first, but continue to update it as your expectations of the future take on more concrete form. Write down that plan on paper (not just as a file on a computer-- paper is more convincing!)

No employer expects that you spend your entire working life with them, but job-hopping every few months will come back to bite you. It creates the impression that you are not reliable, because you are not going to be around long enough to invest in. Plan to stay in a position for at least a year.

Thursday, June 12, 2014

Feedburner link was incorrect. Fixed.

For those of you that still have this blog on your reading list (thank you!) and subscribe to the RSS feed via Feedburner, it must have been even quieter than normal!

It looks like the Feedburner feed fell over some time last year, and you haven't been getting updates since then. Oops.

Now, I haven't really posted all that much since then, but I fixed the feed nevertheless. Hopefully you will see fresh content start appearing again.

Thursday, May 29, 2014

TrueCrypt's demise

As of the time of writing TrueCrypt is pretty much gone. The two most likely scenarios explaining what happened are that the developers just gave up and decided not only to abandon their project, but that they adopted a full scorched earth strategy, and give the world a big finger. The alternative explanation is that the TrueCrypt Foundation suffered a full and complete systems compromise.

But it really doesn't matter. It is really irrelevant whatever the root cause may turn out to be.

Because of their lack of communication, and their apparent disregard for the sense of dismay voiced by the infosec community, the TrueCrypt Foundation is no longer trustworthy (assuming it ever was). Consequently, it means that their product also cannot be trusted.

Is it really that black and white? Yes: when it comes to crypto, it is. Cryptography is based on absolute trust. Even the smallest crack in that trust foundation is enough to discard a product.

Assuming that the open source audit comes back clear, it will just provide us with an audit of a snapshot in time; any development taking place after that point (if any) would only be able to slowly regain and rebuild some level of trust if it was done fully in the open, by people who are recognizable and who have a good reputation.

This episode is a great reminder of the fact that monocultures are ridiculously dangerous for availability assurance. To the best of my knowledge, there is NO robust alternative for TrueCrypt's ability to function across platforms. Sure; all major OS'es have their own crypto product. But, as good as they are, they are specific for the platform on which they were built.

My use case is that I want to be able to mount a volume (read-only and/or read-write) across platforms. My typical use of TrueCrypt was having the encrypted volume sit on Dropbox and accessing it from all of my devices. Semi-sensitive documents were kept there. Now I have to find another way of doing it.

For enterprise planning, it really shows the need for reliable backups. Make sure you keep original installation media for software, in a particular version, and do not assume that you can just download it again when you need it. Yesterday's events show, once more, that to not be the case.

Update: It looks like the TrueCrypt developers threw the towel into the ring themselves. More info at

Monday, March 10, 2014

Fundamental lessons learned from recent data breaches

Higher Education has seen its fair share of data breaches recently. This past week, the University of Maryland, Indiana University, the University of North Dakota, and Johns Hopkins University announced breaches.

The good news is that, slowly, breach notifications are starting to become a little more informative, which provides us with good opportunities to reflect on our own infrastructure.

Such reflection doesn't have to take forever, or lead to bulky reports. For example:

University of Maryland: Full compromise of a system used to manage ID cards and data exfiltration of PII. Root cause of impact of the breach: Excessive proliferation of private information.

University of Indiana: Web server was reconfigured to lower its security posture, while PII was posted. Root cause: Insufficient change management in production configurations and lack of awareness with regards to the location of PII.

University of North Dakota: Unauthorized access to an account with privileged access. Unknown how access was obtained. Root cause: weak authentication and possibly insufficient access control.

Johns Hopkins University: A coding error in a public-facing website allowed access to a back-end database. Root cause: insufficient coding standards (or executive of such standards), excessive access to back-end database,  combined with lack of active vulnerability scanning.

From these four breaches, we can learn a few higher level lessons:
  • Identify and limit data collection and proliferation to necessity, rather than convenience.
  • Actively manage vulnerabilities, both in terms of detection as well as in terms of remediation.
  • Implement strong authentication, including password recovery protocols.
  • Implement strong access control.
  • Implement strong audit trails.
  • Develop and implement hardened configurations and manage changes.
With all of this, it is imperative that higher management is informed transparently and fully. Make sure that you are not the highest person in the hierarchy who realizes what risks exist, what the likelihood of exploitation is, and what the impact would be.

Looking back at our own environment, we can identify where we are lacking, and then plan a path to improve how we identify and manage risks. Subsequently, we can work to obtain funding and buy-in, and get to work.

Thursday, February 20, 2014

University of Maryland data breach

Unfortunately, the University of Maryland has the dubious privilege of listing itself  among data breach victims. A message posted to the University's web site notifies the public of some 300,000 records containing private information that have been breached.

I am not going to speculate about the root cause of the breach, but I am hopeful that more details will become available as time progresses. The fact that there is an active law enforcement investigation does not help in obtaining transparency though.

The message itself did contain a lot of good information. Enough that I want to highlight some of it here:

"Last evening, I was notified [...] that the University of Maryland was the victim of a sophisticated computer security attack that exposed records containing personal information. "
The fact that the notification went out less than 24 hours after their president was informed is telling. It could mean that relevant information did not trickle up fast enough, or that the institution either has a very well developed incident response plan and/or very strong senior leadership. Assuming it is the latter, such fast notification deserves compliments. Publicly acknowledging a data breach in less than 24 hours after the top-level official is aware is commendable.
"A specific database of records [...] was breached yesterday."
Detecting a data breach in less than 24 hours is a fantastic job. Although it must have been a really bad day for their security team, their analysts can be proud of a job well done.
"That database contained 309,079 records of faculty, staff, students and affiliated personnel from the College Park and Shady Grove campuses who have been issued a University ID since 1998. The records included name, Social Security number, date of birth, and University identification number. No other information was compromised -- no financial, academic, health, or contact (phone, address) information."
This is extremely detailed and definitive information. It appears that the institution has a good grasp of the data that is in their custody, and that they were able to pull these numbers together very quickly. While it may appear trivial to do so, it is often a very complex thing to do in an enterprise environment.
"The University is offering one year of free credit monitoring to all affected persons. Additional information will be communicated within the next 24 hours on how to activate this service."
The credit monitoring deal is more or less expected these days. What is notable is that, again, there is a strong commitment by the leadership to be unambiguous and (very) timely. The phrase clearly states what will happen, and when it will happen by.

They continue with a warning that is very appropriate:
"University email communications regarding this incident will not ask you to provide personal information. Please be cautious when sharing personal information."
Having this amount of personal information breaches will, most likely, to targeted phishing attacks, if nothing else. Including this warning might not help all that much, but at least they tried! The fact that they limit the warning to email communication is a little troubling though.
"We recently doubled the number of our IT security engineers and analysts. We also doubled our investment in top-end security tools. Obviously, we need to do more and better, and we will. "
For a public statement by person in a senior leadership position to distinguish engineers and analysts is something we also do not see all that often. Engineers build, and should be involved in any and all software development, adoption, or usage decision making. Analysts monitor for signs of trouble and investigate alarms. Both roles are important and should not be confused.

"Recently" is not further quantified, so we really cannot tell much from that aspect of the statement.

"Again, I regret this breach of our computer and data systems. We are doing everything possible to protect any personal information that may be compromised."
The statement owns the fact that something bad happened. It does not try to cover up, minimize, or even deny that something unfortunate has happened. It also speaks of a commitment to minimize the impact of the damage that has been done.

All in all, I feel sorry for the University of Maryland that they have to go through this, but their initial response to the breach seems to be commendable, and is a sign of strong leadership in a time of crisis.

Friday, January 24, 2014

Cloud Services and Business Continuity

The fact that cloud services are popular deserves no further attention. Plenty is written about that, including elaborate pieces about security and business continuity. However, as much as people are aware that using cloud services may introduce risks to availability, very few realize what the impacts of an outage can be. 

Today's gmail outage, as brief as it was, illustrates that.

Corporate IT typically has visibility and control of at most 5% of the entire infrastructure needed to deliver cloud services. A good service provider with extensive vertical integration may control up to about 15%. That still means that the remaining 80% is beyond either party's direct visibility and control. 

While these numbers nothing more than a (good) estimate, they reflect something that is a little scary when really considered.

I make it a point to really outline this risk issue during a product selection process, and again at our annual business impact analysis meetings.It is important to make sure that all stakeholders explicitly acknowledge (and accept) the fact that cloud services will be unavailable and that alternative processes must in place to accommodate for that.

For some reasons, many business units are more inclined to believe an external service provider's claim that it must be "your IT department", even when those claims can be countered with proof. Having acknowledgement (and acceptance) of outage risk in writing, whether it is in meeting minutes that have been formally accepted, or in the form of email messages is very useful and may be a career saver.

Thursday, November 7, 2013

Readings on Cryptography

Cryptography is sometimes referred to as the first line of defense, as well as the last line of defense in cyber security. Both are true, depending on perspective. Whatever it may be, it is hard to argue with the opinion that modern cryptography has tremendous benefits, if it is implemented well. On the flip side, if it is done wrong, cryptography adds noting more than complexity and it creates a (false) sense of security, which may actually harm you in the long run.

Cryptography is as much about choosing the right cipher, as it is about getting the operational processes in place, and sticking to them.

As the people around me can attest to: statistics and mathematics are not my strong suit. Yet, in light of the whole "our spying agency spies!"-discussion, I have been doing a lot of reading about cryptography lately .

I do not claim that I am a cryptographer. Even more so, I claim that I am definitely not a cryptanalyst.

However, any information security / cyber security practitioner should at least be aware of the history of cryptology (cryptography + cryptanalysis), as well having some level of understanding as to what crypto can (and cannot) do.

Having an understanding of the mathematics behind cryptography is generally not needed. Having a good understanding of crypto operations, however, is a must.

My reading list:

The Code Book, by Simon Singh. A great place to start-- the book strikes the right balance between history, anecdote and it illustrates some of the more common cryptographic elements that you find in many textbooks as well, but it does so in an easy-to-read, and easy-to-follow format. Highly recommended.

The Code Breakers, by David Kahn. Arguably the most comprehensive writeup on the history of cryptography. The book of loaded with historic facts, anecdotes, and explanation of ciphers and codes. The book really does a great job at illustrating that the whole NSA spying story is nothing new-- espionage, intercepts, and code breaking has been happening for thousands of years. We've just gotten a lot better at it lately, and since we communicate more than ever, the reach (and impact) of automated spying is much larger.

Understanding Cryptography, by Christof Paar. Here we shift from gentle storytelling to hard-core math. Not for the faint of heart, but since the book is paired with video lectures on the authors website, it is actually very informative.

Code Breaking, by Rudolph Kippenhahn. The jury is still out on this one. I've only just started reading this, but so far, it seems to fit somewhere between the Code Book and The Code Breakers.

The interesting part of this, is that each of these books is cheap. $11 for the cheapest (The Code Book) to about $50 for The Code Breakers. The amount of value that you get from each of these is absolutely a good deal.

Any other reading recommendations are highly appreciated.