DIY Lock Pick Set

Here's another very interesting post on lock-picking, like making a padlock shim out of soda can: How to make your own lock-picking tools from a windshield wiper. Of course, the skills that come with it, plus the ethics of when it's acceptable to use it, are just as important (if not more).

After you've picked that up, try a copy of Practical Lock Picking: A Physical Penetration Tester's Training Guide or The Complete Book of Locks and Locksmithing.

Deconstructing a Safe Room

All State Insurance's blog has an interesting "infographic" on how safe rooms (storm shelters, panic rooms) work.


There's good general information in there, but note the lack of anything that might assist the home owner in defending himself from a human physical threat.


Also note a big architectural mistake in their diagram: the entry doors open outwards! The safest design is inward opening doors. In the case of a tornado, earthquake, bomb, whatever, if debris leaning against the safe room door and you are inside, you probably will be stuck inside waiting for somebody to find you if your doors open outwards. If your doors open inwards, you are more likely to dig through the debris and dig out. That is an important detail!

A Firearm In Every Room

This is an interesting article about securely concealing a locked firearm in nearly every room in the house for home security.


Why? Why not? Or how about: because he can? A firearm will not deter violence if it's locked up and inaccessible, however, if it's locked up but very accessible it could deter violence. Even better would be for the homeowner to responsibly carry the firearm whenever possible, including inside the home.


Note that the safe chosen is the same make as the safe chosen in the Securology article on Selecting a Pistol Safe.

How to Shim Open a Padlock On the Cheap

This is a quick, cheap, and simple way to crack open a padlock with a homemade shim from a soda can. Not a new idea, but a well-described set of instructions.

When Professor Matt Blaze published "Safecracking for the Computer Scientist", he received all sorts of negative feedback. There were things in his paper that were known vulnerabilities to all locksmiths for perhaps as long as a century, yet they were not fixed in future designs of locks. Publishing this info does not harm the public, since criminals already know how to do this. But publishing allows consumers of these lock products to be wiser. Master lock (depicted at right) has certainly known about this vulnerability for decades. It's been floating around the internet at least since the dot-com boom days.

FBI Violent Crime Stats

The FBI released their report of all crime stats from the first 6 months of 2011 and violent crime dropped another 6.4%.

Also noteworthy, record gun sales to private citizens in 2011.

IBM's 5 Year Predictions

IBM just release five predictions for the next five years. Clearly, somebody has one of "those" kinds of jobs at IBM-- you know, the kind of non-producing "think tank" jobs. Anyway, let's just take a look at this bit of insanity right here:

"[In five years,] You will never need a password again."

There are 3 types of authentication schemes. Say them with me:

1. Something you know
2. Something you have
3. Something you are

Passwords, passphrases, etc., are "something you know". Whoever at IBM wrote that is as foolish as the day is long. The entire "something you know" authentication scheme is not going to disappear just because IBM wants to sell you thinkpads and other devices with biometrics (something you are). You can change a password. You can't change your fingerprints, retinas, etc. (well, not affordably any way).

When a meth-head steals your credit card number (something you have), you call the bank (or they call you) and you get issued a new number. If they steal your thumb, well ... you're not going to grow a new one.

The only way passwords are going away is if their next prediction comes true:

"[In five years,] Mind reading is no longer science fiction."

If that's the case, maybe you won't have to type your password. But if that's the case, you'll have way worse problems than whether or not your authentication scheme is based on "something you know".

Pescatore is BIG GOVERNMENT

Well, another SANS NewsBites editor just admitted to being a BIG GOVERNMENT proponent in today's NewsBites commentary. John Pescatore, who is also a VP of Gartner when he's not playing the role of SANS NewsBites editor, just wished the Internet Security thugs on the rest of us:

THE REST OF THE WEEK'S NEWS
--MySQL.com Compromised Through Blind SQL Injection Attack
(March 28, 2011)
Attackers broke into Oracle's customer website for SQL, MySQL.com, over the weekend using a blind SQL injection attack. The intruders posted information taken from the site, including usernames and password hashes. The unknown attackers also published information about the structure of the databases on the website.
http://www.computerworld.com/s/article/9215249/MySQL_Web_site_falls_victim_to_SQL_injection_attack?taxonomyId=17
http://www.h-online.com/security/news/item/MySQL-allegedly-hacked-via-SQL-injection-1216281.html
[Editor's Note (Pescatore): You know how Public Health departments force restaurants to close for a period of time after they have a sewage backup or roach infestation? I'd like to see similar things happen to commerce websites after they are shown to be vulnerable to well known attacks.]
[Emphasis added by Securology]

What if the Big Government Internet Security bureaucrats shutdown RSA because of the recent SecurID breach and the public internet health "sewage" that resulted? As much as I don't like the situation, and don't like RSA's response, it makes much more sense to let the market decide-- and the market currently is. Organizations are switching away from RSA SecurID based on the breach-- they don't need a Government Public Internet Health Bureaucracy to tell them.

Everybody will get breached given enough time. Does that mean that some governing bureaucrat should shut everyone down, in the name of public safety, security, or "health" on the Internet?

It would be great if SANS would focus on security and not politics.

RSA SecurID Breach - Seed Record Threats

The following is a threat model that assumes the RSA SecurID seed records have been stolen by a sophisticated adversary, which is probably what happened.

But first, a word from our muse, Bruce Schneier, regarding what he titled back in 2005 as the "Failure of Two Factor Authentication":

Two-factor authentication isn't our savior. It won't defend against phishing. It's not going to prevent identity theft. It's not going to secure online accounts from fraudulent transactions. It solves the security problems we had ten years ago, not the security problems we have today.
[snip]

Here are two new active attacks we're starting to see:

• Man-in-the-Middle attack. An attacker puts up a fake bank website and entices user to that website. User types in his password, and the attacker in turn uses it to access the bank's real website. Done right, the user will never realize that he isn't at the bank's website. Then the attacker either disconnects the user and makes any fraudulent transactions he wants, or passes along the user's banking transactions while making his own transactions at the same time.
• Trojan attack. Attacker gets Trojan installed on user's computer. When user logs into his bank's website, the attacker piggybacks on that session via the Trojan to make any fraudulent transaction he wants.

See how two-factor authentication doesn't solve anything? In the first case, the attacker can pass the ever-changing part of the password to the bank along with the never-changing part. And in the second case, the attacker is relying on the user to log in.

[Snip]

Two-factor authentication ... won't work for remote authentication over the Internet.

Bruce was absolutely right. We saw examples of that.

...

Now, let's put the pieces together-- the active MITM attacks that Bruce described, which could result in an offline/passive attack.

In both cases above, the adversary has to act immediately to essentially take over an authenticated session, using either the real-time MITM scenario, or the trojan scenario. But let's assume that the "good guys" have, by now, read Bruce's article [but in all reality, they probably haven't, hence they have an RSA SecurID investment] and have paid attention to the RSA jabber that says to watch for an increase in login attempts. In these examples Bruce describes, the adversary grabs the session and disconnects the valid user (possibly at the presentation layer, by taking over the session in malware that doesn't display what the actions are occurring in the authenticated session).

However, let's assume the adversary let's the user keep his authenticated session. The adversary just monitors the credentials that are entered:

1. The User ID, and
   
2. The one-time-passcode (token's readout, a.k.a. "tokencode", plus the user's PIN)

"Relax," says the security administrator. "That's what these RSA SecurID thingies are for-- to make it meaningless when a bad guy eavesdrops on credentials."

Well, except in the case where the "bad guy" has all of the seed records for all RSA SecurID tokens ever sold.

Quoting from our article from yesterday:

Assume an adversary has now in their possession, all of the seed records for all RSA SecurID tokens that are currently valid (which based on above and previous seems very plausible). Assume they have sufficient computing hardware to mass compute all of the tokencodes for all of the tokens represented by those seed records for a range of time (they obviously are well funded to get the "Advanced Persistent Threat" name). This would be the output of the RSA SecurID algorithm taking all the future units of time as input coupled with the serial number/token codes to generate all of the output "hashes" for each RSA SecurID token that RSA has ever made. These mass computed tokencodes for a given range of time would basically be one big rainbow table, a time computing trade-off not too unlike using rainbow tables to crack password hashes.
[Snip]
Since tokencodes are only 6 digits long, and RSA has sold millions of tokens, the chances of a collision of a token's output with another token's output at a random point in time is significant enough, but phish the same user repeatedly (like asking for "next tokencode") and the adversary now can significantly narrow down the possibilities of which tokens belong to which user because different tokens must appear random and not in sync with each other (otherwise RSA SecurID would have much bigger problems). Do this selectively over a period of time for a high valued asset, and chances are the adversary's presence will go undetected, but the adversary will be able to determine exactly which token (serial number, i.e. seed record) belongs to the victim user.

So, now that the adversary has these "rainbow tables" of RSA SecurID tokencodes, and now that the active attacks Bruce described have morphed into a passive attempt, all it will take is watching particular users create valid sessions-- maybe as little as a single attempt, depending upon the mathematics and randomness of the RSA SecurID token output, but probably more like watching a handful of attempts. At that point, the adversary can then impersonate the victim user at any point in the future.

So, if RSA SecurID seed records are compromised, there is really not much advantage in an RSA SecurID implementation. The threats are essentially the same as an adversary grabbing conventional passwords. The only difference is that a passive attack against compromised seed records may take multiple monitoring attempts, as opposed to a single event. But with simple malware, that won't be much more effort, especially for a high valued asset.

So given what we know, we can assume seed records were compromised. And given how little RSA is talking about it, we cannot really know how they are responding to it. Will they just distribute new tokens without compromised seed records, or will they do something much more significant? Based on what we know today, it makes more sense for an organization that is thinking about an RSA SecurID deployment to rely instead on conventional passwords (e.g. Microsoft Active Directory), and spend the extra money on monitoring for fraud and stronger identity validation for things like password resets.

More RSA SecurID Reactions

RSA Released a new Customer FAQ regarding the RSA SecurID breach. Let's break it down ...

Customer FAQ

Incident Overview

1. What happened?

Recently, our security systems identified an extremely sophisticated cyber attack in progress, targeting our RSA business unit. We took a variety of aggressive measures against the threat to protect our customers and our business including further hardening our IT infrastructure and working closely with appropriate authorities.

Glad to see they didn't use the words "Advanced Persistent Threat" there.

2. What information was lost?

Our investigation to date has revealed that the attack resulted in certain information being extracted from RSA’s systems. Some of that information is related to RSA SecurID authentication products.

Hmmm. Seed Records possibly?

3. Why can’t you provide more details about the information that was extracted related to RSA SecurID technology?

Our customers’ security is our number one priority. We continue to provide our customers with all the information they need to assess their risk and ensure they are protected. Providing additional specific information about the nature of the attack on RSA or about certain elements of RSA SecurID design could enable others to try to compromise our customers’ RSA SecurID implementations.
[Emphasis added by Securology]

Whoa! Pause right there. Obviously they have allowed somebody from a Public/Customer Relations background to write this. This is not coming from anybody who *knows security*.

Like we mentioned previously, Kerckhoff's Principle and Shannon's Maxim dictate that the DESIGN be open. These ideas are older than the Internet, and pretty much older than computing itself. So, disclosing the RSA SecurID DESIGN should have no adverse affect on customers with implementations unless the DESIGN is flawed to begin with.

Realistically, this is PR-speak for obfuscating details about what was stolen. All things point to seed records. Source code to on-premise implementations at customer sites shouldn't be affected, because those components aren't facing the Internet, and generally who cares about them? Yes, it's possible to hack the backend through things like XSS (think "Cross Site Printing"), but the state-of-the-art would be to compromise it from the outside using weaknesses found at RSA headquarters: seed records.

4. Does this event weaken my RSA SecurID solution against attacks?

RSA SecurID technology continues to be an effective authentication solution. To the best of our knowledge, whoever attacked RSA has certain information related to the RSA SecurID solution, but not enough to complete a successful attack without obtaining additional information that is only held by our customers. We have provided best practices so customers can strengthen the protection of the RSA SecurID information they hold. RSA SecurID technology is as effective as it was before against other attacks.
[Emphasis added by Securology.]

If it wasn't obvious that it's seed records yet, it should be screaming "SEED RECORDS" by this point. RSA SecurID is a two factor authentication system, meaning you can couple your RSA SecurID time synchronized tokencode with a PIN/Password. So, if the seed records are stolen, then the only way an adversary can impersonate you would be if he knew:

1. Which RSA SecurID token is assigned to you (i.e. the serial number stored in the RSA SecurID database on-site at a customer's site)
   
2. Your PIN/Passcode that is the second facto (i.e. another piece of information stored in the customer's site).

More evidence that the RSA breach was seed records: the serial number and seed records give the adversary half the information needed, but the rest is stored on-site.

5. What constitutes a direct attack on an RSA SecurID customer?

To compromise any RSA SecurID deployment, an attacker needs to possess multiple pieces of information about the token, the customer, the individual users and their PINs. Some of this information is never held by RSA and is controlled only by the customer. In order to mount a successful direct attack, someone would need to have possession of all this information.


6. What constitutes a broader attack on an RSA SecurID customer?

To compromise any RSA SecurID deployment, the attacker needs to possess multiple pieces of information about the token, the customer, the individual users and their PINs. Some of this information is never held by RSA and is controlled only by the customer. In order to mount a successful direct attack, someone would need to have possession of all this information.

The broader attack we referenced most likely would be an indirect attack on a customer that uses a combination of technical and social engineering techniques to attempt to compromise all pieces of information about the token, the customer, the individual users and their PINs. Social engineering attacks typically target customers’ end users and help desks. Technical attacks typically target customers’ back end servers, networks and end user machines. Our prioritized remediation steps in the RSA SecurID Best Practices Guides are focused on strengthening your security against these potential broader attacks.
[Emphasis added by Securology]

This PR person is beginning to agree with us. Yes, the seed records are the hard part. If you are an RSA SecurID customer, assume the adversary has them, and now watch out for the pieces you control.

7. Have my SecurID token records been taken?
[Emphasis added by Securology.]

Yes, it's obvious they have.

For the security of our customers, we are not releasing any additional information about what was taken. It is more important to understand all the critical components of the RSA SecurID solution.

To compromise any RSA SecurID deployment, the attacker needs to possess multiple pieces of information about the token, the customer, the individual users and their PINs. Some of this information is never held by RSA and is controlled only by the customer. In order to mount a successful attack, someone would need to have possession of all this information.

This is beginning to look like a broken record.

8. Has RSA stopped manufacturing and/or distributing RSA SecurID tokens or other products?

As part of our standard operating procedures, while we further harden our environment some operations are interrupted. We expect to resume distribution soon and will share information on this when available.

Of course manufacturing/distribution has stopped. Of course anyone worried about security would have an SOP that says "stop shipping the crypto devices when the seed records are compromised." This is just more evidence that the seed records were compromised.

[...snipped for brevity...]
13. How can I monitor my deployment for unusual authentication activity?

To detect unusual authentication activity, the Authentication Manager logs should be monitored for abnormally high rates of failed authentications and/or “Next Tokencode Required” events. If these types of activities are detected, your organization should be prepared to identify the access point being used and shut them down.

The Authentication Manager Log Monitoring Guidelines has detailed descriptions of several additional events that your organization should consider monitoring.
[Emphasis added by Securology]

Warning about failed authentication and next tokencode events further indicates the seed records were stolen, because this would indicate the adversaries are guessing valid tokencodes but invalid PINs, or guessing tokencodes in order to determine a specific user's serial number (to match stolen seed records with a particular user).

14. How do I protect users and help desks against Social Engineering attacks such as targeted phishing?

Educate your users on a regular basis about how to avoid phishing attacks. Be sure to follow best practices and guidelines from sources such as the Anti-Phishing Working Group (APWG) at http://education.apwg.org/r/en/index.htm.

In addition, make sure your end users know the following:

• They will never be asked for and should never provide their token serial numbers, tokencodes, PINs, passwords, etc.

Because giving that away is giving away the last parts of information that are "controlled only by the customer", i.e. the mapping of UserIDs to seed records via token serial numbers.

• Do not enter tokencodes into links that you clicked in an email. Instead, type in the URL of the reputable site to which you want to authenticate

Because a phishing attack that takes a tokencode could be all that is needed to guess which serial number a user has, since that moment in time could be recorded, and all seed records could be used in a parallel, offline attack to compute their token codes at that instance in time. Assume an adversary has now in their possession, all of the seed records for all RSA SecurID tokens that are currently valid (which based on above and previous seems very plausible). Assume they have sufficient computing hardware to mass compute all of the tokencodes for all of the tokens represented by those seed records for a range of time (they obviously are well funded to get the "Advanced Persistent Threat" name). This would be the output of the RSA SecurID algorithm taking all the future units of time as input coupled with the serial number/token codes to generate all of the output "hashes" for each RSA SecurID token that RSA has ever made. These mass computed tokencodes for a given range of time would basically be one big rainbow table, a time computing trade-off not too unlike using rainbow tables to crack password hashes. Then assume the adversaries can phish users into providing a tokencode into a false login prompt. Since tokencodes are only 6 digits long, and RSA has sold millions of tokens, the chances of a collision of a token's output with another token's output at a random point in time is significant enough, but phish the same user repeatedly (like asking for "next tokencode") and the adversary now can significantly narrow down the possibilities of which tokens belong to which user because different tokens must appear random and not in sync with each other (otherwise RSA SecurID would have much bigger problems). Do this selectively over a period of time for a high valued asset, and chances are the adversary's presence will go undetected, but the adversary will be able to determine exactly which token (serial number, i.e. seed record) belongs to the victim user. Or do it in mass quickly (think: social media) and it will harvest many userIDs to serial numbers (seed records) which would be valuable on the black market-- especially for e-commerce banking applications.

It is also critical that your Help Desk Administrators verify the end user’s identity before performing any Help Desk operations on their behalf. Recommended actions include:

· Call the end user back on a phone owned by the organization and on a number that is already stored in the system.

· Send the user an email to a company email address. If possible, use encrypted mail.

· Work with the employee’s manager to verify the user’s identity

· Verify the identity in person

· Use multiple open-ended questions from employee records (e.g., “Name one person in your group” or, “What is your badge number?”). Avoid yes/no questions

Important: Be wary of using mobile phones for identity confirmation, even if they are owned by the company, as mobile phone numbers are often stored in locations that are vulnerable to tampering or social engineering.
[...snipped for brevity...]

The above is very decent advice, not unlike what we posted recently.


So, in summary: yeah, yeah, yeah, seed records were stolen. Little to no doubt about that now.

RSA SecurID Breach - Initial Reactions

RSA, the security division of EMC, was breached by a sophisticated adversary who stole something of value pertaining to RSA SecurID two factor authentication implementations. That much we know for certain.


It's probably also safe to say that RSA SecurID will be knocked at least a notch down off their place of unreasonably high esteem.


And it wouldn't hurt to take this as a reminder that there is no such thing as a perfectly secure system. Complexity wins every time and the adversary has the advantage.


First, note that the original Securology article entitled "Soft tokens aren't tokens at all" is still very valid as the day it was published over 3 years ago. CNET is reporting that RSA has sold 40 million hardware tokens and 250 million software tokens. That means that 86% of all RSA SecurID "tokens" (which are of the "soft token" variety) are already wide open all of the problems that an endpoint device has-- and more importantly, that 86% of the "two factor authentication" products sold and licensed by RSA are not really "two factor authentication" in the first place.


Second, we should note the principles in economics, so eloquently described by your mother as: "don't put all your eggs in one basket", i.e. the principle of diversification. If your organization relies solely on RSA SecurID for security, you were on borrowed time to begin with. For those organizations, this event is just proof that "the emperor hath no clothes".


Third, the algorithm behind RSA SecurID is not publicly disclosed. This should be a red flag to anyone worth their salt in security. This is a direct violation of Kerckhoff's Principle and Shannon's Maxim, roughly that only the encryption keys should be secret and that we should always assume an enemy knows (or can reverse engineer) the algorithm. There have been attempts in the past to reverse engineer the RSA SecurID algorithm, but those attempts are old and not necessarily the way the current version operates.


Fourth, it's probably the seed records that were stolen. Since we know that the algorithm is essentially a black box, taking as input a "seed record" and the current time, then either disclosure of the "seed records" or disclosure of the algorithm could potentially be devastating to any system relying on RSA SecurID for authentication.

Hints that the "seed records" were stolen can be seen in this Network World article:

But there's already speculation that attackers gained some information about the "secret sauce" for RSA SecurID and its one-time password authentication mechanism, which could be tied to the serial numbers on tokens, says Phil Cox, principal consultant at Boston-based SystemExperts. RSA is emphasizing that customers make sure that anyone in their organizations using SecurID be careful in ensuring they don't give out serial numbers on secured tokens. RSA executives are busy today conducting mass briefings via dial-in for customers, says Cox. [emphasis added by Securology]

Suggesting to customers to keep serial numbers secret implies that seed records were indeed stolen.

When a customer deploys newly purchased tokens, the customer must import a file containing a digitally signed list of seed records associated with serial numbers of the device. From that point on, administrators assign a token by serial number, which is really just associating the seed record of the device with the user's future authentication attempts. Any time that user attempts to authenticate, the server takes the current time and the seed record and computes its own tokencode for comparison to the user input. In fact, one known troubleshooting problem happens when the server and token get out of time synchronization. NTP is usually the answer to that problem.

This further strengthens the theory that seed records were stolen by the "advanced persistent threat", since any customer with a copy of the server-side components essentially has the algorithm, through common reversing techniques of binaries. The server's CPU must be able to computer the tokencode via the algorithm, therefore monitoring instructions as they enter the CPU will divulge the algorithm. This is not a new threat, and certainly nothing worthy of a new moniker. The most common example of reversing binaries is for bypassing software licensing features-- it doesn't take a world-class threat to do that. What is much, much more likely is that RSA SecurID seed records were indeed stolen.

The only item of value that could be even more damaging might be the algorithm RSA uses to establish seed records and associate them with serial numbers. Assuming there is some repeatable process to that-- and it makes sense to believe there is since that would make production manufacturing of those devices more simple-- then stealing that algorithm is like stealing all seed records: past, present, and future.

Likewise, even if source code is the item that was stolen, it's unlikely that any of that will translate into real attacks since most RSA SecurID installations do not directly expose the RSA servers to the Internet. They're usually called upon by end-user-facing systems like VPNs or websites, and the Internet tier generally packages up the credentials and passes them along in a different protocol, like RADIUS. The only way a vulnerability in the stolen source code would become very valuable would be if there is an injection vulnerability found in it, such as passing a malicious input in a username and password challenge that resulted in the back-end RSA SecurID systems to fail open, much like a SQL injection attack. It's possible, but much more probable that seed records were the stolen item of value.


How to Respond to the News

Lots of advice has been shared for how to handle this bad news. Most of it is good, but a couple items need a reality check.


RSA filed with the SEC and in their filing there is a copy of their customer support note on the issue. At the bottom of the form, is a list of suggestions:

• We recommend customers increase their focus on security for social media applications and the use of those applications and websites by anyone with access to their critical networks.
• We recommend customers enforce strong password and pin policies.
• We recommend customers follow the rule of least privilege when assigning roles and responsibilities to security administrators.
• We recommend customers re-educate employees on the importance of avoiding suspicious emails, and remind them not to provide user names or other credentials to anyone ...
• We recommend customers pay special attention to security around their active directories, making full use of their SIEM products and also implementing two-factor authentication to control access to active directories.
• We recommend customers watch closely for changes in user privilege levels and access rights using security monitoring technologies such as SIEM, and consider adding more levels of manual approval for those changes.
• We recommend customers harden, closely monitor, and limit remote and physical access to infrastructure that is hosting critical security software.
• We recommend customers examine their help desk practices for information leakage that could help an attacker perform a social engineering attack.
• We recommend customers update their security products and the operating systems hosting them with the latest patches.
  

[emphasis added by Securology]

Unless RSA is sitting on some new way to shim into the Microsoft Active Directory (AD) authentication stacks (and they have not published it), there is no way to accomplish what they have stated there in bold. AD consists of mainly LDAP and Kerberos with a sprinkling in of a few other neat features (not going into those for brevity). LDAP/LDAPS (the secure SSL/TLS version) and Kerberos are both based on passwords as the secret to authentication. They cannot simply be upgraded into using two-factor authentication.

Assuming RSA is suggesting installing the RSA SecurID agent for Windows on each Domain Controller in an AD forest, that still does not prevent access to making changes inside of AD Users & Computers, because any client must be able to talk Kerberos and LDAP to at least a single Domain Controller for AD's basic interoperability to function-- those same firewall rules for those services will also allow authenticated and authorized users to browse and modify objects within the directory. What they're putting in there just doesn't seem to be possible and must have been written by somebody who doesn't understand the Microsoft Active Directory product line very well.


Securosis has a how-to-respond list on their blog:

Remember that SecurID is the second factor in a two-factor system… you aren’t stripped naked (unless you’re going through airport security). Assuming it’s completely useless now, here is what you can do:

1. Don’t panic. We know almost nothing at this point, and thus all we can do is speculate. Until we know the attacker, what was lost, how SecurID was compromised (if it is), and the vector of a potential attack we can’t make an informed risk assessment.
2. Talk to your RSA representative and pressure them for this information.
3. Assume SecureID is no longer effective. Review passwords tied to SecurID accounts and make sure they are strong (if possible).
4. If you are a high-value target, force a password change for any accounts with privileges that could be overly harmful (e.g. admins).
5. Consider disabling accounts that don’t use a password or PIN.
6. Set password attempt lockouts (3 tries to lock an account, or similar).

[Emphasis added by Securology]

To their first point, I think we can know what was lost: seed records. Without that, there would be no point in filing with the SEC and publicly disclosing that fact. Anybody can know their algorithm for computing one-time passwords by reversing the server side (see above). The only other component in the process is the current time, which is public information. The only private information is the seed record.

On point #4, if your organization is a high-valued asset type of a target, flagging RSA SecurID users to change their PINs or passwords associated with their user accounts may not be a good idea, because as the defense you have to assume this well articulated offensive adversary already has your seed records and therefore could respond to the challenge to reset passwords. A better solution, if your organization is small, is to physically meet with and reset credentials for high valued users. If you cannot do that because your organization is too large of a scale, then your only real option is to monitor user behavior for abnormalities-- which is where most of your true value should come from anyway.

This does tie well with their second suggestion-- pressuring your RSA contact for more information. In all likelihood, if our speculation that seed records were indeed stolen, then the only solution is to demand new RSA SecurID tokens from RSA to replace the ones you have currently. And if RSA is not quick to respond to that, it's for one of two reasons:

1. This is going to financially hurt them in a very significant way and it's not easy to just mass produce 40 million tokens overnight, OR,
   
2. RSA's algorithm for generating seed records and assigning them to token serial numbers is compromised, and they're going to need some R&D time to come up with a fix without breaking current customers who order new tokens under the new seed record generation scheme in the future.

UPDATED TO ADD: Since all things indicate the seed records were compromised, and since Art Coviello's message is that no RSA customers should have reduced security as a result of their breach, then that must mean RSA does not believe SecurID is worth the investment. After all, if RSA SecurID seed records were stolen, it effectively reduces any implementation to just a single factor: the PIN/passwords that are requested in addition to the tokencode. And who would buy all that infrastructure and handout worthless digital keychains when they can get a single factor password authentication for super cheap with Microsoft's Active Directory?

Euphemism: Advanced Persistent Threat

Seems like the buzz phrase of the day is: "Advanced Persistent Threat", given the context of RSA's breach. Let's be clear: we don't need yet-another-security-phrase, and we certainly aren't very good at taxonomies (nothing fits into neat little boxes).


So let's just call it what it is: RSA got {hacked, breached, cracked, pwned}. Do we really need yet-another-word to describe it? Not hardly.


Think about it. The term "Advanced Persistent Threat" can only exist to serve two purposes:

1. To look good on a power point slide from some security vendor's sales guy. "Boy, I'm scared about those APTs, boss, so can you please fund our bazillion dollar budget so I can buy that anti-APT-ware?"
   
2. To appear like a legitimate excuse for when an organization is breached, so rather than sending the CISO's head rolling, he can say "Sorry, it was an Advanced Persistent Threat." The CEO and stockholders: "Wow. We have literally no idea what that is, so we don't think we can do your job, and we probably need to hang onto your employment a bit longer."
   

Isn't the whole Internet just one big threat that persists day after day and gets more and more advanced as time goes along?


So, if Art Coviello is trying to say "Please don't fire me or stop buying RSA products-- these bad guys are good at what they do," then why can't he just come out and say that instead?


The last thing the IT Security industry needs is more tasteless marketing hype.


Realistically, we get it: RSA had a dedicated adversary that probably used a variety of means to illicitly steal what they wanted from RSA. That's the worst kind of adversary, but it's not a new kind of adversary. And we certainly don't need a new buzz word to describe that kind of adversary.

State of the Art Self-Defense Training

Since there are many recent posts on physical security here lately, and on firearms in particular... I just came across this post about Gander Mountain's new state-of-the-art training facility. There are numerous interesting features, from a virtual shooting range to a virtual reality simulator using simulated firearms in self-defense. This is probably one of the best ways somebody could put themselves into a realistic physical threat scenario without actually being in one-- and it's certainly the safest way I have ever seen.

Unintended Consequences of Illinois FOID Firearm Permit Disclosure

The Illinois Attorney General just ordered that the records of all Illinois residents who have FOID permits to own a firearm to be released upon demand to anyone in the public.

To quote Yogi Berra: "this is like deja vu all over again."

A little over a year ago, Illinois's next door neighbor, Indiana, also demanded the release of similar information about gun owners. I had predicted there would be unintended consequences, including how criminals would use the records as a way of "pre-casing" potential robbery locations, screening all known firearm owners' addresses off the lists, because so many addresses without firearms owners are out there. FBI's repeated interviews of incarcerated felons demonstrates time and time again that felons don't like to rob people who *may* be armed. In fact, I went on to say:

"This may be the online equivalent of putting this yard sign in your neighborhood."

Then, ironically, just as I predicted, Indiana wised up on firearms owner records:

Now, it appears state representative Peggy Welch or her constituents read "The Unintended Consequences of Searchable Gun Registries". Look at what she said to the Indianapolis Star:

Rep. Peggy Welch, D-Bloomington, authored House Bill 1068 to restrict access to gun-permit information after The Star and the Bloomington Herald-Times published databases and stories about gun ownership. Neither newspaper published names and addresses of people who had concealed-weapon permits, but Welch told the committee her constituents were alarmed nonetheless.

"It wasn't just people who owned guns," she said. "It was people who didn't own guns and said, 'I don't like the idea that somebody can know I don't have a permit, which may make them think that I don't have a gun and come and rob me,' " Welch said. [Emphasis is mine]

Note that the politician in opposition to releasing Indiana's firearm owner records was a Democrat (which tend to be opposed to citizen possession of firearms). Yet, the understanding that this has a negative security impact transcends the political position.

So, what will happen in Illinois? Well, history tends to repeat itself.

If you are of the camp that believes less crime happens when less people have firearms, you will soon realize that publicizing *who* has firearms and who doesn't (while society is on its path to approaching zero firearms) actually reduces the security of those not on the list.

If you are in the camp that believes less crime happens when more people have firearms-- and if your address is in the list of known Illinois FOID owners-- you will soon learn that your personal and physical security is probably the same or slightly better than BEFORE the records are published, while your disarmed neighbors' security has been significantly reduced.

Also noteworthy is this is happening as the Illinois state assembly considers becoming the 49th state to allow concealed carry of firearms.


My prediction: Same as before in Indiana. People will wake up and realize that the release of firearms owner information will reduce the security of those who aren't on the list.

TSA Screening Upon Exit of Train Stations

The Department of Homeland Security's Transportation Security Administration (TSA), long criticized by legitimate security experts, just got caught setting up shop in a train depot and requiring passengers who were exiting the train to be screened:





What is the threat model being used here? Who or what is the threat? Is the TSA concerned about the safety and security of those on the train? Apparently not.

Blogger Bob at the TSA suggests the TSA made a mistake since the passengers were routed back into the depot building when they were otherwise free to go (all people entering the building are now apparently subject to pat-downs and other intrusive searching):

It should be noted that disembarking passengers did not need to enter the station to claim luggage or get to their car.

Signs such as the one shown here are posted at the entrance to the impacted area.

However, after looking into it further, we learned that this particular VIPR operation should have ended by the time these folks were coming through the station since no more trains were leaving the station. We apologize for any inconvenience we may have caused for those passengers.

Why Magazine Limits Don't Improve Security

All firearm politics aside, if the intent of legislation is to reduce the likelihood of mass shootings, all that a high-capacity magazine limit (e.g. prohibiting possession of all magazines with more than 10 rounds as is proposed in the current Congress) will accomplish is to slow down bad shooters who do not have access to high capacity magazines from a black market.

This video demonstrates what a practiced shooter can do with lower capacity magazines in short order. It should be quite clear that a high magazine capacity ban will do nothing to prevent a shooter of this skill level from wreaking significant havoc. Therefore, a high capacity magazine ban is nothing short of false sense of security-- security theater.

So, from a threat modeling perspective, the only threat that a high-capacity-magazine-ban policy will accomplish is the equivalent to script kiddies in the computer security world. And in the computer security world, script kiddies are generally just a nuisance, not a dangerous threat against anyone except those too inept to follow basic security principles. So, such a policy either doesn't handle all the relevant threats, or such a policy as it is used in modern American politics does not disclose how narrow its focus is in terms of only applying to less proficient threats. Either way, it's a failure from a threat modeling perspective.

Back to the drawing board.

Alan Paller Trusts the Government

Alan Paller (of SANS, pictured left) trusts the U.S. Government. Don't you?

From a recent SANS Newsbites:

"In case you missed his speech yesterday, General Alexander (head of NSA and the US Cyber Command) told 4,000 people that the US Cyber Command will test a program of sharing classified attack signatures with private industry if those organizations can protect the sensitive data. That sharing will enable private organizations to set up early warning and filtering systems that are as up to date as the systems that protect DoD networks. Very cool.

Alan"

Nothing could ever go wrong with this, right?

Alan Paller is waving his hand and saying "these are not the droids you're looking for", as in, don't pay attention to the fact that some of the computer systems with the worst security are the U.S. Government's systems. And they say so themselves with their own audits and failing "F" grades.

But moving past that ... And don't look at this from the perspective of the IPS signatures as being very sensitive pieces of data that only the DoD should know. Think about it from the process and how this might be leveraged by rogue or corrupt individuals within the U.S. government.

For example ... Do most organizations manually add IPS signatures? No. What do they do instead? They use automated feeds, just like software updates or signatures for anti-virus. For this program that Alan Paller mentions to be successful on any degree, it would require building a mechanism to automate the fetching of the signatures from the DoD (no doubt with a couple layers of crypto/authentication involved because the DoD thinks they're "sensitive"), and then the participating organizations will automate the import of those signatures. After all, that's the point of IPS, right-- to not manually review each connection, let alone each packet?

Once the participating organization incorporates these into their Intrusion Prevention Systems, then the U.S. Government effectively controls the traffic to/from these organizations' networks.

Of course, for the first round-- the beta test-- the IPS signatures will be benign and the whole process will be very well monitored. But as it grows and expands-- or worst case as it's mandated by some federal law to all organizations, a la the CyberSecurity Act-- the opportunity for corruption will then follow. At that point, a government official could then decide they don't like traffic that looks, say, politically dissenting, and they could craft a signature that matches on common dissenting speech and start filtering free speech right there-- in a private organization that, like Alan Paller, thought it was "very cool" to trust the DoD's IPS signatures.

A more appropriate response: "Very scary! Why would I ever risk my business on that?".


No thanks, Alan Paller, SANS, and your oh-so-big-nanny-state government, we can do security just fine for ourselves. Probably better, in fact.

Seven Types of Hackers

This could also be titled "Taxonomies are Difficult".
...


Roger Grimes at InfoWorld has a Seven Types of Hackers article. Taxonomies are generally tough to do, and I think Roger could improve upon his list a bit. Let's break it down ...

Malicious hacker No. 1: Cyber criminals
Professional criminals comprise the biggest group of malicious hackers, using malware and exploits to steal money. It doesn't matter how they do it, whether they're manipulating your bank account, using your credit card numbers, faking antivirus programs, or stealing your identity or passwords. Their motivation is fast, big financial gain.

The #1 problem I have with this label is that all of the activities in the list are typically "crimes" in most jurisdictions. Therefore, people who participate in them are "criminals". And "Cyber" is an annoying word on many levels, but Joe Sixpack will associate that term with computers. I would have chosen "Petty Thieves" as a better label for this category.

Malicious hacker No. 2: Spammers and adware spreaders
Purveyors of spam and adware make their money through illegal advertising, either getting paid by a legitimate company for pushing business their way or by selling their own products. Cheap Viagra, anyone? Members of this group believe they are just "aggressive marketers." It helps them sleep at night.

I am not sure how "adware spreaders" fits for a good taxonomy name, but generally agree this is a legitimate category in and of itself.

Malicious hacker No. 3: Advanced persistent threat (APT) agents
Intruders engaging in APT-style attacks represent well-organized, well-funded groups -- often located in a "safe harbor" country -- and they're out to steal a company's intellectual property. They aren't out for quick financial gain like cyber criminals; they're in it for the long haul. Their dream assignment is to essentially duplicate their victim's best ideas and products in their own homeland, or to sell the information they've purloined to the highest bidder.

Malicious hacker No. 4: Corporate spies
Corporate spying is not new; it's just significantly easier to do, thanks to today's pervasive Internet connectivity. Corporate spies are usually interested in a particular piece of intellectual property or competitive information. They differ from APT agents in that they don't have to be located in a safe-harbor country. Corporate espionage groups aren't usually as organized as APT groups, and they are more focused on short- to midterm financial gains.

I find Category #3 ridiculously similar to Category #4. The only difference is whether they are free-lance (#3) or directly on the payroll (#4). Either way, I'd collapse these two categories into a single category.

Malicious hacker No. 5: Hacktivists
Lots of hackers are motivated by political, religious, environmental, or other personal beliefs. They are usually content with embarrassing their opponents or defacing their websites, although they can slip into corporate-espionage mode if it means they can weaken the opponent. Think WikiLeaks.

Hacktivisism may be a webism, but it's probably it's own category-- political activism through criminal operations on computer systems.

Malicious hacker No. 6: Cyber warriors
Cyber warfare is a city-state against city-state exploitation with an endgame objective of disabling an opponent's military capability. Participants may operate as APT or corporate spies at times, but everything they learn is geared toward a specific military objective. The Stuxnet worm is a great example of this attack method.

I despise the term "cyber warrior" or its parent "cyber warfare". Call it what it is: militaries and their contractors attacking each other. Criminal operations involving computers for a militaristic goal. So a much better title: Military & Military Contractors.

Malicious hacker No. 7: Rogue hackers
There are hundreds of thousands of hackers who simply want to prove their skills, brag to friends, and are thrilled to engage in unauthorized activities. They may participate in other types of hacking (crimeware), but it isn't their only objective and motivation. These are the traditional stereotyped figures popularized by the 1983 film "War Games," hacking late at night, while drinking Mountain Dew and eating Doritos. These are the petty criminals of the cyber world. They're a nuisance, but they aren't about to disrupt the Internet and business as we know it -- unlike members of the other groups.

I'm also not a big fan of this label. It could just as easily be called "Internet Graffiti".


Taxonomies are difficult-- very difficult-- to lay down on paper (or bits). If I were grading this one, I'd give it about a B- or maybe a B. It's far from grade A material, but it has its entertainment value.

Swiss Keep their Security

It is good to see the Swiss voted to maintain their personal and national security this past weekend. Their citizen militia and their famously neutral stance on world affairs have kept the small alpine nation free of external threats of violence.

While critics cite suicides were done using military-issued (citizen militia) firearms, the number is small, and there is no evidence that suggests these suicides would have been prevented had the firearms not been present-- just that maybe the suicides would have used some other weapon tool to complete the task. It's sadly too difficult to interview the deceased to know for sure.

Congratulations to the Swiss!

DNS Hijacks are Unnecessary

DHS, in the name of "save our children", hijacked 84,000 DNS domain names by accident, leaving visitors to those websites confused and believing that various small businesses were associated with child pornography trafficking.

Since nobody else is mentioning this-- we'll ask it here: Why can't we just stick with the FBI's old practice of getting a warrant to collect the hardware involved with the alleged child pornography trafficking? That method would not have accidentally accused 84,000 website owners of being involved when they weren't-- some of which are probably facing irreparable damage to their small business's image now. If the hardware was collected under a search warrant, the worst case would have been some innocent websites would have had unreachable servers, which would just appear like a web hosting technical difficulty instead of accusing a person or organization of highly illegal and immoral behavior.

Hey DHS: Hijacking DNS domain names is totally unnecessary unless you want to maintain your Orwellian Big Brother image and potentially sabotage small businesses when we need them most: in the worst economy in 100 years.

When will Apple learn?

Apple still hasn't fixed the gaping hole on their "secure" and "enterprise ready" new iPhones models. It's over a year old now, barely even acknowledged (I have had Apple Security Engineers deny its existence to my face and then say "oh ... no comment" when I pointed them to the original article sources).


Now, it's yet another hack-- probably related to the first hack. This time, a person holding your lost iPhone can have all of your passwords from the safety of the iOS KeyChain in mere minutes.

It looks very similar to Jonathan Zdziarski's original work, but remember that Zdziarski won't share his work with others, unless you're law enforcement (because he profits more personally that way by charging exorbitant "training" fees from law enforcement, i.e. Zdziarski's taking tax dollars for his own purse and we're all worse off because he's not sharing his code).