Tuesday, February 14, 2017

Let's Talk About Passwords


There was a lot of talk about passwords after White House Press Secretary Sean Spicer supposedly tweeted his password not once but twice. 



The password was a random 8 character string composed of numbers and characters.  This password in itself is not a terrible password.  The new draft NIST guidelines (https://pages.nist.gov/800-63-3/sp800-63b.html#sec5) regarding passwords recommend passwords at least 8 characters in length.  For the tl;dr version of the guidelines, let’s review.

  • Minimum 8 characters
  • Passwords should be rejected if found to be on a blacklist of compromised values
  • No password expiration
  • Store the password using an approved password hashing algorithm such as PBKDF2 (I prefer bcrypt)
  • Implement two-factor authentication

Microsoft published their own password guidance which echoes these requirements.  Microsoft dives deeper and explains why passwords greater than 10 characters in length can result in worse passwords, not better.  The guidance is worth the read (https://www.microsoft.com/en-us/research/wp-content/uploads/2016/06/Microsoft_Password_Guidance-1.pdf).

Password composition requirements are only one part of securing the authentication workflow.  With no other protections, the password could be brute forced within minutes.  There is also a difference between online and offline attacks.

Online Attacks
Online attacks happen when a malicious user attempts to login to someone else’s account.  To defend against this kind of attack, the first line of defense is implementing a lockout after a certain number of failed attempts.  This is typically set fairly low to keep attackers from trying to brute force their way into someone’s account.  As long as the password is somewhat complex, an attacker will have a difficult time getting in.  That is why NIST recommends banning the use of passwords commonly found on lists from password dumps from data breaches.  Passwords such as “Password” should be banned as these are some of the most common passwords and will be the first passwords to be attempted. 

If an attacker is successful in guessing or obtaining a user’s password then the second line of defense is to implement two-factor authentication (2FA) to protect against online attacks.  Two-factor authentication can be implemented in any number of ways but involves generating a one-time passcode (OTP) either using a time-based approach (TOTP) or hash-based approach (HOTP).   The OTP is communicated through a number of ways:

  • E-mail
  • SMS
  • Soft token
  • Hardware token
·       
The point is, not only does the attacker need to obtain the user’s password but they also must be able to obtain the OTP that usually has a short life (no more than 5 minutes according to NIST guidelines).

Offline Attacks
The strength of a password is tested during an offline attack.  NIST guidelines recommend using a password hashing mechanism such as PBKDF2 to properly store passwords at rest.  Algorithms such as PBKDF2 are meant to slow down the process of hashing the passwords and prevent password cracking rigs from cracking as few passwords as possible.  Using Sean Spicer’s password as an example, because it doesn’t show up in any commonly used password lists, it would be near impossible using today’s technology to crack it during an offline attack if somehow the password hashes were dumped. 

Summary
Sean Spicer’s password really is not that insecure assuming the government took action to implement other controls around the authentication workflow.  To summarize:
  • Banning passwords found on commonly-used password lists from previous breaches
  • Implementing an account lockout mechanism to protect against online attacks
  • Implementing two-factor authentication
  • Properly storing passwords using an approved password hashing algorithm
An organization can be well on its way to having an effective authentication workflow if they follow these simple steps.  But someone should probably still have a talk with Spicer about OPSEC.

Sunday, November 6, 2016

AppSec: The Redheaded Stepchild



Back in 2014, when Microsoft disbanded their Trustworthy Computing Group responsible for setting the direction of Microsoft’s cybersecurity efforts, the decision was met by confusion.  The employees who didn’t get laid off were split between the legal department and Cloud & Enterprise.  How would the security efforts led by the Trustworthy Computing group live on under new departments whose mission was not solely focused on security?  There are a couple of competing views about this move and this is why AppSec is the redheaded stepchild in the security industry.  Where does AppSec belong?  Should AppSec live in the infosec department or the software development department?  Does anyone really want to own AppSec?

AppSec Belongs in Software Development

I am reminded of a quote from Dinis Cruz (@DinisCruz) from his AppSecEU presentation.  Dinis said “The best way to determine if you have an AppSec program is to ask if those guys can program.  And the second question is would the development teams hire them?  If your development teams would not hire the guys that currently do AppSec then you don’t have AppSec.”  This quote really struck me.  It’s brutally honest.  The role of the AppSec team should be to work with the developers to write secure code.  How can you help developers write secure code if you have never developed code before?  It is not enough to tell developers to use parameterized queries to prevent SQL injection.  An AppSec engineer should be able to show the developers how to implement parameterized queries in the chosen language.  For example, in Java just using the PreparedStatement class is not enough to prevent SQL injection even though some developers think it is.  When interviewing a candidate for the AppSec team you would have developers interviewing the candidate and quizzing them on programming concepts.  Not only should the candidate be competent about these concepts but they should also have the chemistry to fit in with the culture on the development teams.  This can only be achieved by having developers involved in the interview process.  Furthermore, senior management would have to account for AppSec initiatives in their budget and scheduling.  This gives AppSec a bit more leverage when they propose new initiatives.  When AppSec is consuming someone else’s budget there is less motivation for development teams to play nice.  Enough can’t be said about AppSec sitting next to developers and being involved in side conversations and whiteboard sessions that often happen when AppSec is on another floor.

AppSec Belongs in InfoSec

There’s a certain culture that security professionals share.  These professionals bond over vulnerabilities, breaches, and security conferences.  The job of AppSec often overlaps with GRC (governance, risk management and compliance), TVM (threat and vulnerability management), and Red Team.  AppSec works with GRC to develop security requirements to comply with regulations and help GRC understand the risk of application vulnerabilities.  TVM deals with breaches and this involves pulling in AppSec to understand how a vulnerability was exploited in a home-grown application.  Red Team performs pen tests and works with AppSec to develop fixes for vulnerabilities that are found.  Having all of these teams sit in the same room provides many benefits that aren’t seen when AppSec sits on a different floor.  The CISO of an organization is responsible for the overall security posture of the organization which includes home-grown applications and thus drives AppSec initiatives.  Sitting in the SOC gives AppSec a unique view into the current threats facing an organization.  These threats are presented in real time and gives team members a chance to respond immediately if needed.  There are certain characteristics security professionals possess and which are required that might not be obvious to people outside of security.  This gives InfoSec the unique ability to identify candidates with the right security mindset required for the job. 

So what’s the answer?  Where should AppSec live?  In a perfect world, InfoSec and Development would share responsibility for the AppSec team.  During the interview process, both departments should be involved in the process to avoid hiring a candidate who is incompatible with either department.  We don’t live in a perfect world so where the team lives depends on the organization’s philosophy.  For Microsoft, it made sense to move their security team to the development side of the house.  This would be my preference for where AppSec lives, but that’s the developer in me talking.  I sit in the SOC with the InfoSec teams and there are times I miss being involved in design discussions with developers. 


Thursday, October 27, 2016

You had one job!

Recently, it was reported Weebly suffered a massive data breach that included usernames and password hashes.  But the good news is the passwords were hashed using bcrypt with a work factor of 8.  While I would have preferred to have seen a stronger work factor there is no faulting the team that is responsible for storing passwords since they used a very secure hashing algorithm to store passwords.  Kudos to the team at Weebly that was responsible for storing passwords.  You had one job!  And congratulations, you did it very well.

A common response from developers is “if our network gets penetrated then we are already screwed so why should I worry about validating input coming from this internal source?”  Every application, whether it’s homegrown or 3rd party, is part of a larger ecosystem in an organization.  Whether it’s a firewall, a file sharing application, or a billing system, these all provide an opportunity for a hacker to penetrate an organization.  As long as the rest of the ecosystem is hardened a hacker won’t be able to penetrate further.  This is what is meant by “you had one job!”  Developers need to develop their applications assuming the rest of the ecosystem will be compromised at some point.  Assuming your organization’s ecosystem is hostile is not a mindset most developers have.  Awareness training is great to get this point across but a better method to demonstrate how these attacks can occur is threat modeling the application which includes being attacked from within the application’s ecosystem.  Showing how malicious data can be spread from a compromised application to other applications is a great scenario to work out.  Get your Red Team involved to develop proof of concepts.  Record these proof of concepts so the videos can be viewed by anyone wanting a demonstration of how these attacks occur.  Seeing an attack in your own ecosystem is much more effective than reading about an attack against another organization’s application.  

The Weebly team responsible for password storage is breathing a sigh of relief today because they did their job.  They aren’t having an uncomfortable conversation with the security team because they improperly hashed the passwords.  More importantly, the users can rest assured knowing their passwords are still safe.  Do your job and the rest will take care of itself.

Friday, August 26, 2016

Communication for Dummies



I have been doing this computer thing for a dozen years now.  I started out as a developer and migrated over to the dark side, aka application security.  I have read lots of blogs and books on various security and software topics.  I have attended a number of conferences including Black Hat, BSides and OWASP.   I always come away with really awesome ideas on new processes and technologies.  I am always excited to get back to work and implement these ideas to help my organization.  I put in all of that hard work and finally unveil the final product and… nothing.  Well shit, none of the speakers at the conference or authors of the blogs or books I read talked about how to actually communicate these new ideas to the people who have to use the new process or technology.  Think about all of the conferences you have attended and all of the blogs you have read.  How many times have you read about how to effectively communicate these ideas to the developers who have to implement them?  

Communication is a key area that I’m actively working to improve, both personally and professionally.  I realized a long time ago that I have a slight temper and this affects my ability to communicate effectively.  There are times when it takes every bit of patience I have not to tell a developer their code is complete horse crap.  This isn’t effective and won’t help get vulnerabilities fixed.  The approach that should be taken is that of a teacher, but not a teacher that gives you detention for not turning in your homework.  As security professionals we should take this approach more often rather than scolding users, developers, operations, etc.  Instead of scolding a developer for not using parameterized queries to prevent SQL injection the better approach is to educate them.  Sit down and fix a couple of the vulnerabilities together while teaching the developer how to use parameterized queries.  

Avoid confrontation whenever possible.  Getting into a debate about whether a piece of code is vulnerable is not effective.  Instead, emphasize that while there might be no clear way to exploit the vulnerability, the code does not meet secure coding standards and that is the ultimate goal.  If developers follow secure coding standards, then there will never be a debate about whether or not code is vulnerable.  My organization conducts annual security training which stresses secure coding standards and we also have a policy that codifies the use of secure coding standards.  Because the organization has bought into using secure coding standards it is easy to leverage this mandate while in discussions with developers.  

Keep your ears open and your mouth shut.  Sometimes the best communication is not to say anything at all and just listen.  Seek out those in more senior positions and observe how they communicate with people.  Pay attention to how they respond in tense situations when another person is losing their temper.  I can remember observing a mentor of mine when he was being confronted with people looking for a confrontation.  My mentor stayed calm and collected.  He stayed on topic and would continue to offer different solutions looking for a compromise.  The person who is losing their cool might have a point so pay attention to what they are saying.  This will help diffuse the situation.

As for those cool ideas you got from the conference you just attended, make sure to have a plan for implementation.  Don’t just go to the developers, hand them a spec and say they have 3 months to implement this.  Explain your vision and why this idea is critical to achieving the organization’s goals.  Come up with short term goals so you can get some quick wins and explain the long term goals of the project.  Most importantly, don’t let the developers think you’re not invested in this project as much as they are.  If the developers see you working hard towards the end goal they won’t have an issue working with you.