Last month I gave a talk at SIRAcon 2016, “STPA-Sec: stealing from safety engineering to improve threat modeling.” The talk was well received, and I want to thank both the organizers and attendees for an excellent conference.
The talk was the result of my attendance at the 2016 STAMP workshop. STAMP includes a couple of frameworks that are used within the safety profession, both for hazard analysis (STPA) and accident analysis (CAST). There are a handful of security researchers involved with the group (mainly from MIT Lincoln Labs) and they have developed a version that can be applied to security, STPA-Sec.
STPA has been shown to identify hazards more efficiently and effectively than traditional safety methods such as fault tree analysis, identifying more hazards in a shorter period of time, and I believe STPA-Sec can do the same for information risk analysis, by more effectively identifying and communicating risks than existing threat modeling techniques. Even so, STPA-Sec is still a work in progress, and I found gaps in the model when applying it to a simple banking application: it does not directly address confidentiality as that isn’t generally a safety concern.
You can download the slides from SIRAcon here.
This article originally appeared on information-safety.org
Earlier this year, I spoke at CyberSecureGov 2016, after my proposed talk based on the two years I spent working on large government projects was accepted. Identity & Access Management has always been an interest of mine, ever since my days supporting a security administration team, and I learned quite a bit by working on projects setting up single sign-on for the public.
From the Abstract:
Building Identity & Access Management solutions can be difficult. This presentation reviews lessons learned from designing and building IAM solutions in multiple states, focusing on the unique challenges of IAM in government, which must serve the needs of three separate groups: the public, government agencies, and NGOs. Lessons drawn from real-world experiences will demonstrate what works, what doesn’t, and how to fix things when they go wrong.
Following the flow of a typical user’s experience, the presentation will cover the successes, and failures of designing an IAM solution: getting a user ID, logging in to the system, matching “me” as a public user to “my data,” and getting access to the system. Along the way, we will explore lessons about how design choices for each step can impact that experience.
Also covered are designs that were not implemented, sharing the vision of how automated user-driven access requests, changes, and reviews can both improve user experience and lower costs.
The key lesson for me was to understand that there are three key aspects of enrolling users in a public website, that should be handled separately: provisioning a user ID, identity matching, and identity proofing. Making these separate processes solves many potential problems and provides a better user experience.
One interesting thing I noticed in both talks is that there were a small core of very interested attendees – most security professionals don’t have to deal with Identity & Access Management, but those who do tend to be very passionate about the topic, and could easily relate to the problems we faced while building out large SSO solutions.
Today I completed some long overdue maintenace for transvasive.com – a number of links were broken due to a prior migration, and general churning of the internet. All links have been fixed, except for links that have permanently broken, which were left as-is for posterity. All assets stored locally on the site are working, please contact me if you find issues.
Copyright © 2012 Brophey Consulting and Transvasive Security. All rights reserved.
I spoke today at OWASP AppSec USA on “Building Predictable Systems using Behavioral Security Modeling: Functional Security Requirements.” Although Karl Brophey was not able to join me, he was there in spirit. The talk was an updated version of our presentation at Secure360 earlier this year.
Here is a copy of the slides from the talk. OWASP will be posting a free video as well (thanks!) and I’ll add a link when that becomes available. Below is a the abstract and link to the white paper we wrote, which explains the ideas presented in the talk in greater detail.
Defining functional security requirements is a key component of Behavioral Security Modeling, a method to improve security through accurately modeling human/information interactions in social terms. The paper proposes a practical, SDLC agnostic method for gathering functional security requirements by establishing limits on interactions through a series of questions to identify, clarify, and uncover hidden constraints. Five categories of constraints are presented, along with advice and “requirement patterns” to facilitate discussions with stakeholders and translate business needs into unambiguous security requirements. General advice on improving constraints, implementation considerations, security actions, quality assurance, and documenting post conditions are also discussed.
I didn’t get much from the two morning talks given by two of the sponsors, although the discussion on fuzzing from Codenomicon was new to at least one person I spoke to, and I did like Mikko Varpiola’s observation that the barrier to entry for cybercrime is generally quite low.
Tina Meier, of the Megan Meier Foundation, spoke over lunch about cyberbullying and related issues – as you may recall, Tina’s daughter Megan committed suicide after a cyberbullying incident involving a fake identity created with the help of an adult neighbor. It’s a sad story, one that found me reflecting on how the easy anonymity, deception, and social distance created by the internet can increase both the likelihood and impact of bullying behavior. How do we teach people how information works? That “on the Internet, nobody knows you’re a dog,” and that once posted or emailed, information can never really be recalled or removed, and can easily be made public?
The day was rounded out by a good panel on how to turn research into innovation, with thoughts on establishing MN as a center for cyber security, much as it is for the medical device industry. The final talk by Patrick Reidy, the current CISO of the FBI was the highlight of the day for me. Patrick made some excellent points about APT – that it’s an intelligence effort that should be addressed with counterintelligence, covered insider threat (creative ways of spotting malicious insiders), and focused on people more so than the technology, actually using the phrase “positive social engineering!” In one example, by asking users to confirm that a risky action was appropriate (surfing to a file sharing website, like Google Docs), the FBI reduced policy violations by 97% in three months.
Day 2 kicked off with a presentation on the Multi-State MS-ISAC, followed by an excellent prezo given by Nick Selby, a police officer and member of the 451 Group, on what cyber intelligence is, and how & why you would want to build a cyber intelligence function. As Nick says, “intelligence is not sexy,” and is more about knowing what information to throw away than what information to collect. The talk included other quotable moments, such as “Policy is set by throwing knives in the dark,” referring to BYOD/mobile. I would recommend you check out his site, Police-Led Intelligence.
Over lunch a panel discussed the National Strategy for Trusted Identities in Cyberspace (NSTIC), followed by a CISO panel on information sharing. The CISO panel was most interesting to me when I asked about sharing “security failures” – there was none, really. For me, this goes to the heart of the incident-sharing problem: incidents are not failures: they’re cases where the bad guys won a battle but not the war. Certainly companies’ negligence can contribute to incidents, but apart from that, it’s not really their fault they got hacked. As an industry we need to do a better job of not blaming the victim and accepting that incidents WILL happen, and that our job is to manage the impact to an acceptable level.
Finally, at the end of the panel discussion and also mentioned by the final speaker, Mark Weatherford, was the need to develop more cyber security professionals- cyber security unemployment is either zero or negative right now, depending on how you look at it, and the consensus was that we need to reach all the way down to the high school level with our recruitment efforts.
All in all, it was a good two days, and I’ll likely attend next year. I’m not sure I’d recommend it for out-of-state folks, but if you live in the region, it’s a worthwhile conference.
Copyright © 2012 Transvasive Security. All rights reserved.
Today I spoke at the (ISC)2 Security Congress in Philadelphia, which is co-located with the ASIS International Conference. I talked about Behavioral Threat Modeling, which is my proposal for a better way of identifying security design flaws. I enjoyed the talk, and got several good questions at the end.
Although video of the talk is only available to conference participants, I’ve posted a copy of my slides below. For those who would like a copy of the Excel template I used for the Threat Profiles, I’m working on posting a copy here as well, but until then, please contact me and I’ll be happy to email you a copy.
If you happen to live in the Minneapolis / St Paul area, I’ll be giving the talk again at the local OWASP MSP chapter a week from today, on September 17. (It’s the same talk, we just had a problem getting the title right) The OWASP MSP group is fun, and I’m hoping I’ll get some hecklers.
Update: I’ve posted both the slides, and the sample threat profiles, links above.
Copyright © 2012 Transvasive Security. All rights reserved.
Lately, I’ve been thinking about the concept of Information Safety, and how it differs from Information Security. When I talk to people about the idea, especially non-security people, they typically find “safety” more appealing than “security,” but for the concept to pay off, it has to be more than just a re-branding of existing security concepts.
For me, the concept of information safety is an answer to Donn Parker’s challenge to information risk management in 2006. In his article for the ISSA Journal, “Making the Case for Replacing Risk-Based Security,” Donn observes that there are two types of problems information security: ongoing attacks that are virtual certainties, like viruses, and rare, unpredictable incidents. I agree with his observations, but disagree (somewhat) with his conclusion to use a due diligence approach — do what we have always done. For me, information safety is the approach for ongoing & certain attacks, and protection is the approach for the rare & unpredictable.
I recently came across an article published by the American Institute of Architects (by way of Wikipedia) that includes elegant definitions for both security and safety, which highlight the problems within the information security profession that demonstrate the need for a safety practice:
Safety involves whatever contributes to maintaining the “steady state” of a social and physical structure or place in terms of whatever it is intended to do. Safety connotes stability over time, continuity of function and reliability of structure.
Security is the process or means of delaying, preventing and otherwise protecting against external or internal dangers, loss, criminals, and other individuals or actions that threaten to weaken, hinder or destroy an organization’s “steady state,” and otherwise deprive it of its intended purpose for being.
For me, the notion of “steady state” is key to safety. Our current focus on security (what I call “protection”) leads us to focus on protecting against threats, while establishing and maintaining a steady state is undervalued and even neglected. We have information security organizations, but where are our information safety teams?
Copyright © 2012 Transvasive Security. All rights reserved.
You have a computer.
You can install software.
Four things you can do to improve your personal safety.
I recently gave a short presentation at the SkillShare Fair at CoCo, where I spend time working and writing. I pitched it as “The top 4 things you can do to keep your computer safe and secure.” Although the group attending was small, I had a great time, and learned from the participants. It was a test run for a class I’m developing to teach basic computer safety, blending both my experiences giving security advice to friends & family and my concept of Information Safety.
Here is a copy of the slides I used. I mentioned specific products in my talk, since they’re representative of the solutions I like for the typical risks most computer users face – those are listed below.
In my article, “Why Password Rotation is Bad,” I made the case that rotating passwords offers no security benefits, while making them harder for people to use. I stand by my assertion that passwords are hard to use, and rotation only diminishes usability, but I can now say that on a system that implements a password hashing algorithm like bcrypt or PBKDF2, in some cases, password rotation can effectively defeat brute-force attacks, but little protection against dictionary attacks.
bcrypt and PBKDF2 (Password-Based Key Derivation Function 2) work in essentially the same way – instead of salting and hashing the password once, the process is done repeatedly, an arbitrary number of times. (scrypt is a newer alternative that is specifically designed to further resist brute-force attacks) Although adding iterations doesn’t add to the cryptographic strength, it does increase the computing time required to calculate the hash. By increasing the calculation time, we can make password cracking more difficult. Instead of being able to test hundreds of millions of passwords per second, we can slow the attacker to ten per second (at least on one machine with no specialized hardware). The defender can choose a target time for how long it takes to calculate a single hash, and adjust the number of iterations accordingly. The beauty of this approach is that, failing a major breakthrough in mathematics, the number of iterations can be increased over time as computing power increases to keep the calculation time constant. Users’ pasword hashes can be silently upgraded when the number of iterations increases, so that calc times stay constant for legacy hashes.
Practically speaking, this means figuring out how long to make your passwords becomes an exercise in comparing relative computing power of attacker and defender.
For my analysis, I assumed a password has time of 100 ms; this is a reasonable target, as a tenth of a second isn’t going to have much of a negative impact on user experience when logging in. An attacker calculating hashes at the same rate can perform 10 attempts per second, although they could apply additional horsepower to increase the cracking rate. Below are a couple of tables showing the number of days to brute-force a password at a given rate.
Lowercase Letters Only
Number of days to brute-force crack a password of a given length.
Uppercase, Lowercase, and Numbers
Number of days to brute-force crack a password of a given length.
Realistically, hashes only have to withstand attack long enough for the defender to detect that the hash database has been compromised, after which the passwords are all changed or invalidated. If passwords are set to rotate once per year, or if you assume the majority of attacks will be detected within a year, that leads to some interesting conclusions:
|Lowercase Only||Upper, Lower, Number|
Password length required to resist an attack for 1 year (365 days or more).
Three types of attackers are considered, an Average attacker who can check 100x as many passwords per second as the defender, a Strong attacker with 100,000 times capacity, and a Massive attacker with 100 million times capacity. For reference, the largest Botnet on record, Bredolab, had an estimated 30 million systems.
For an Average attacker, any 8-character password will resist a brute-force attack for a year. A “PCI-compliant” 8-character strong password will resist even a Strong attacker for a year. Extending the length to 10 will pretty much prevent any non-government sponsored attack; even a Massive attacker would take 26 years to exhaust the password space (note that some passwords would be found more quickly).
This simple analysis aligns with work done by the developers of scrypt: by their estimates, (p. 14) it would take $130K worth of custom-fabricated 2002 hardware to crack an 8-character bcrypt password and $4.8 million worth to crack an 8-character scrypt password. (Keep in mind these are educated guesses for building ASICs tailored to cracking)
Putting this all together, adding bcrypt (or better yet, scrypt) to contemporary password policies that are already in place at most large companies (8 character, complex password) will protect password hashes against most attackers. Password rotation does improve security, since it puts an upper limit on how long a stolen hash is valid for, but if you assume that password database breaches will be detected in a reasonable time period (12-24 months), then rotation is probably unnecessary. When complexity is not mandatory, even an 8-character all-lowercase password will hold up against an Average attacker.
Unfortunately, bcrypt/scrypt provides little protection against dictionary attacks. Even at 10 attempts per second, an attacker can try 1 million passwords per day; bad passwords will still be guessed very quickly. To defend against this, the only practical approach is to run a dictionary attack against your password database. Some systems allow this to be done at the time the password is set – even a relatively small dictionary, along with good guidance on how to select an acceptable password should provide reasonable protection.
So, to sum up:
- Use scrypt, or a similar password hashing algorithm.
- Set the number of iterations so that hashes take approximately 100 ms, and adjust this value over time as computing power increases.
- Use the same password policy you have today (8 character complex passwords).
- Run dictionary checks against passwords as they are selected.
If you follow all this advice, your passwords will be able to withstand an offline attack long enough for you to discover the breach, removing the need to rotate passwords, and keep you safe against all but the strongest adversaries.
Note however, it doesn’t change my advice for creating passwords for sites you visit, since it’s safe to assume most sites still use relatively weak MD5-crypt or SHA-1 hashes.
Per Thorshiem, a Norwegian security researcher, discovered a file containing 6.5 million SHA-1 unsalted password hashes posted to a Russian hacker site. The poster was requesting help cracking the passwords. Multiple researchers have confirmed that at least some of the passwords are from LinkedIn, by looking for known passwords (i.e. their own) that are only used for LinkedIn, and by examining some of the already-cracked passwords, many of which include the words “link” or “LinkedIn.” The file appears to only contain passwords, and no usernames, but it’s likely the hacker(s) that posted the file have usernames as well. 300,000 have already been cracked.
What does this mean?
Passwords are most often stored as a hash, which transforms the password into a fixed-length value. To check if someone enters the correct password, the system takes the password entered, hashes it, and compares it to the stored hash. If they match, the system allows the login to proceed. In some cases, a salt is added to the password before the hash is done, which makes cracking harder. The salt is a random value that’s stored with the password hash.
The transformation method, in this case SHA-1, encodes passwords is such a way that the only practical method to crack the password is to calculate the hash for a possible password, and compare the hash against the list of 6.5 million. Hackers and security professionals use two methods for cracking: a dictionary attack, which tries a list of words and common passwords, and a brute-force attack, which simply tries each possible password, (aaaaaaaa, then aaaaaaab, …).
Although this may sound difficult, modern software, combined with a fast video graphics card (to do the calculations), can test hundreds of millions of passwords per second against the entire list simultaneously… combine this with the knowledge that humans choose predictable passwords, and passwords can be guessed quite quickly. Already, 300K passwords (about 5%) are known to have already been cracked. Over time, the number of cracked passwords will steadily increase.
What should I do now?
If you use LinkedIn, change your password now. It’s not certain that your password has been or even will be cracked, but it’s a reasonable precaution. If your LinkedIn password is the same as the one you use on other sites, you’ll need to change those too. A common tactic today is to try an already-known password on other sites. See my suggestions below on how I manage my own passwords for how you can make this easier for you and harder for the bad guys.
How can I protect myself against this type of attack?
The standard advice from security professionals is to pick hard to guess “strong” passwords, and pick different passwords for each site you use. This quickly becomes an impossible task; I have well over 100 passwords to keep track of. Some time ago, I gave up on trying to remember passwords and adopted a password manager. A good password manager does the job of both generating unique, random passwords for each site you use, storing them securely, all protected by a single master password, and makes it easy to enter your password when logging on to a website (just click a button!)
Right now, I use 1Password, but also recommend LastPass. I use a very long pass phrase for my master password, which is a phrase or complete sentence that should be easy to remember, but hard to guess. Five or more words is good, and using spaces and punctuation is also good. 1Password has a post that discusses the topic in detail, and I like their example of “I have 35 bats: Larry, Moe & Curly.” LastPass can step up security by allowing you to add a USB device as an additional (second factor) authenticator. I currently don’t have my pass phrase written down, but if you’re forgetful, I’d recommend writing it down, sealing it in an envelope (or a tamper-evident bag if you can get one), and storing it in a safe place, like an actual safe, or your safety deposit box.
For individual websites, I generate a 15-character random password that contains upper case, lower case, and numbers, which is compatible with most sites, and long enough that it’s really unlikely it will ever be cracked using current technology. I don’t use the 1Password built-in generator, but for those who do (it’s easier), I’d recommend setting length to 15 or more, with 1 digit, and 1 symbol for sites that require it. Since 1Password has clients for all my devices, and syncs using Dropbox, I always have my passwords handy.
The net effect of all of this? It’s easier for me to use, since I only have to remember one password that I don’t need to change. It’s harder for the bad guys, since if they manage to steal a site’s password database, they probably won’t be able to crack my password, unless the site is not properly protecting passwords and storing them in plain text. Finally, if I do find out a site has been broken into, fixing the problem is easy: I generate a new password for that site.
For security professionals:
Security professionals I know routinely use the same approach (password managers). My challenge to the community is this: why not adopt this approach for ALL passwords, including the passwords we’re charged to protect? After all, LastPass offers an enterprise edition that solves many of the problems that make passwords insecure. I’d love to hear from you via Twitter (@transvasive) what you think of giving password managers to everyone in your organization: good idea? crazy? something you’ve already implemented? I hope to write more on this topic in the future, and will include what you have to say (with attribution).