Monday, November 10, 2014

Unauthenticated self-service secure password reset

As I am currently in the middle of a process to redesign a secure self-service password reset function, I started to write up a post on do's and don't of password reset. Then, after browsing around a bit, I found this great little gem at http://www.troyhunt.com/2012/05/everything-you-ever-wanted-to-know.html, in which Troy Hunt does an amazing job at documenting what choices you should make, and just as importantly, what the reason is behind each of these design choices.

One thing to add to that post is that, by allowing self-service password reset according to a well-defined and intuitive process, you really do your help desk a great service. However, at the same time, you create a possible weak spot in your security architecture.

Since the reset-function, by its nature, is an unauthenticated web-based process, it is certain that it will attract unwanted attention. Watch it like a hawk, and have an incident response process ready before you bring it live.

Monday, September 8, 2014

The Potential Impact of Point-of-Sale Compromises for Business Continuity Planning

Brian Krebs reported on September 2, 2014 that The Home Depot was the victim of a massive data breach, in which credit card numbers were stolen in large numbers. The Home Depot responded by posting a message claiming that they were investigating the issue. As of today (September 8, 2014) that message has not been updated, assuming that a breach has not yet been determined. However, at the same time. Krebs is already providing information about the exact type of malware used to conduct the heist.

What is very interesting, by lack of a better term, is that this is yet another attack against the point-of-sale infrastructure of a large retail chain. In fact, the alleged breach resembles the Target breach of December of 2013 in many different aspects.

A concerning bit there is that we now know that adversaries are willing and able to compromise large retailers at the PoS terminals in their brick-and-mortar stores. So far, these breaches have been focused on stealing credit card data, which makes me believe that it is the work of criminals.

However, if criminal organizations have these capabilities, it is no stretch to also believe that nation states and/or other organizations driven by ideology, rather than by profit, have the same ability. And, for those with a different moral compass than most of us in the West do, rather than quietly stealing information, they could have the ability to shut down entire PoS infrastructures.

The amount of financial damage, as well as the inconvenience, and possibly fear, that an attack against, say, the PoS infrastructure of organizations like Walmart, Target, or Sears can cause is disconcerting, to say the least.

In our incident response planning, we have been focusing on the first class: data theft. But, how well are we prepared for the second one? Malicious destruction of assets is something that we prepare for in business continuity planning, but those plans seems to mostly focus on natural hazards, like earthquakes, floods, hurricanes, fires, civil unrest, etc.

How well are cyber incident response plans aligned with your business continuity plans?

Thursday, September 4, 2014

Using Security Frameworks to Achieve Effective Cyber Defenses

The cybersecurity community tends to spend a lot of attention to what happens on the offensive side of the line. The latest breaches, vulnerabilities and research projects are generally highly featured, extensively discussed, and good for lots of street credits.

However, just as important as knowing what happens on the offensive side, is being skilled on the defensive side. Possibly with the exception of highly skilled incident responders swooping in to save the day, defensive security is not as sexy, nearly invisible, and, unfortunately, generally under-appreciated.

And that's okay.

Defenders (like me) enjoy building, rather than breaking. We build processes, architectures, people skills, etc. and hopefully keep the bad guys out for another day, while preparing our bosses that, eventually, it will be nearly impossible to keep a determined and well-resourced out.

I had the pleasure of advising Dean Sapp with writing his GIAC Gold paper for the leadership certification. The paper was a pleasure to read, since it focuses mostly in the defensive aspect, while not ignoring the offensive part.

In the paper, Dean describes a Red Team exercise in which penetration testers successfully compromise a corporate database containing sensitive information. The exercise is repeated after the defensive team took the time to implement a subsection of the SANS critical controls. This time, the results are much different and the defenses held.

Having security frameworks like the SANS critical controls, the ISO 27000-series, the Australian DoD top 35 mitigations, or even the PCI DSS and the NIST Cybersecurity Framework offer valuable insights to defenders, and, as this paper illustrates, even implementing a small subsection of just one of those controls can be a great service to your organization.

Dean's paper How the SANS Critical Controls Prevent the Red Team from P0wning your Database can be found here.

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.

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

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

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

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

Plan
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 https://www.grc.com/misc/truecrypt/truecrypt.htm

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.