Carnegie Mellon has conducted a study in which they proved the predictability of Social Security Numbers in the U.S. given that date and location of birth are known. Because it is a common practice to tie an individual's SSN to his/her bank accounts, phone bills, drivers license, or practically anything, I'd love to see whether organizations in the U.S. will move more and more toward what their counter parts in Europe are doing -- namely to check the individual's social security number, the government ID number, and various other details about the individual.
This study will also be presented at BlackHat at the end of July.
Jul 7, 2009
Jun 24, 2009
Web Security 101
Mike has released a set of webcasts that cover Web security for beginners. These webcasts, including the slides, are available here. Mike's announcement and comments are available here.
Labels:
security
Jun 22, 2009
Defining a leader
Recently I've found the following quote from this page:
So from a pure economic/business perspective, how do you define a leader? Is it in terms of sales? Is in terms of customers? Is it in terms of capability/throughput? Or is it simply in terms of head count?
The thought that provoked this post are simply this: many companies these days present themselves as leaders in something. Whether it's technology, ability to handle big projects, or throughput, everyone these days claims the to be a leader. As D says, they could be leaders in one thing compared to their competitors, but lack in something else.
I think marketing is trying to get a competitive advantage once again. ;)
The team of more than 600 professionally trained consultants is three times larger than that of any other competitor, and makes the company a leader in the constantly developing Bulgarian market.
So from a pure economic/business perspective, how do you define a leader? Is it in terms of sales? Is in terms of customers? Is it in terms of capability/throughput? Or is it simply in terms of head count?
The thought that provoked this post are simply this: many companies these days present themselves as leaders in something. Whether it's technology, ability to handle big projects, or throughput, everyone these days claims the to be a leader. As D says, they could be leaders in one thing compared to their competitors, but lack in something else.
I think marketing is trying to get a competitive advantage once again. ;)
Labels:
daily life
Jun 16, 2009
Secure the textbook
Coop, a good friend of mine, is starting an initiative to revise college textbooks that teach software engineering and weed out insecure practices from them. The goal of this project is to bring security awareness throughout the entire computer science curriculum and not in just 1-2 courses. If you're interested in participating in this effort, go check out the project site.
Labels:
security
Jun 10, 2009
Threat modeling: bringing it all together
There are few ways to do threat modeling. For those that are in the financial sector, it's all about business risks. For those in the technology sector, it's all about fending off direct attacks. What both approaches have in common is the fact they all try to identify and counter any event that may offset the normal order of operation within a given business process. One at the business level, while the other at the more technical level. Because both approaches have different starting and ending points, there is the risk of having gaps in the overall risk analysis process.
Why do I say this? If we look at the technical threat modeling exercise, everything begins with identifying the individual assets and the threats that affect them. The gap in this approach is that the application's business goals are not stated clear. Protecting assets is good, but why do they need to be protected? How do you convey to your higher-level management and external stakeholders that a particular asset needs protection? You simply speak in terms that can be understood by your audience: business goals. Similarly, if you look at the business risk analysis exercise, how do you ensure that the security test/audit of your application will cover all venues of attacking your system? How can you provide documentation of adequate security assessment coverage at the time of a breach? You simply provide your test plan, which is most likely derived from the attack vectors and pre-conditions in your threat model.
So what's the purpose of complicating things? As risk analysis is an essential part of ensuring any system's security, it is also essential that the report that is produced during this analysis provide meaningful, yet actionable information. Here are the steps that can help achieve that:
1. Gather information on the business goals of the system.
2. Identify the business risks that will harm those business goals.
3. Decompose the business risks into technical risks that can realize if a security breach occurs.
4. For each technical risk, build a tree of attack vectors that lead to the realization of this technical risk.
5. For each attack vector, identify the pre-conditions that are necessary for this attack vector to execute.
6. Using the attack vectors, their pre-conditions, and your knowledge of the system's attack surface, draft a document (most likely a test plan) that covers all possible venues of attack.
Thoughts?
Why do I say this? If we look at the technical threat modeling exercise, everything begins with identifying the individual assets and the threats that affect them. The gap in this approach is that the application's business goals are not stated clear. Protecting assets is good, but why do they need to be protected? How do you convey to your higher-level management and external stakeholders that a particular asset needs protection? You simply speak in terms that can be understood by your audience: business goals. Similarly, if you look at the business risk analysis exercise, how do you ensure that the security test/audit of your application will cover all venues of attacking your system? How can you provide documentation of adequate security assessment coverage at the time of a breach? You simply provide your test plan, which is most likely derived from the attack vectors and pre-conditions in your threat model.
So what's the purpose of complicating things? As risk analysis is an essential part of ensuring any system's security, it is also essential that the report that is produced during this analysis provide meaningful, yet actionable information. Here are the steps that can help achieve that:
1. Gather information on the business goals of the system.
2. Identify the business risks that will harm those business goals.
3. Decompose the business risks into technical risks that can realize if a security breach occurs.
4. For each technical risk, build a tree of attack vectors that lead to the realization of this technical risk.
5. For each attack vector, identify the pre-conditions that are necessary for this attack vector to execute.
6. Using the attack vectors, their pre-conditions, and your knowledge of the system's attack surface, draft a document (most likely a test plan) that covers all possible venues of attack.
Thoughts?
Labels:
security
Jun 8, 2009
Finding Software Insecurities through Password Policies
There are a few main security strategies to consider when using password controls within an application:
- Users should always be forced to use fairly complex passwords
- Unless used with legacy software, passwords should always be salted and hashed (even encryption doesn't cut it as there are no other valid reasons besides legacy software that mandate that passwords must be recoverable)
Earlier I landed on this blog post by Johannes Ullrich from the SANS Institute. The bit that I like the most is:
- Users should always be forced to use fairly complex passwords
- Unless used with legacy software, passwords should always be salted and hashed (even encryption doesn't cut it as there are no other valid reasons besides legacy software that mandate that passwords must be recoverable)
Earlier I landed on this blog post by Johannes Ullrich from the SANS Institute. The bit that I like the most is:
Usually, if a site is imposing [maximum] limits to your password, like the length or it doesn’t allow certain characters, you can guess that your password will be stored in the clear.
The reason is simple: If the password is hashed, then it doesn’t matter how long it is, or what characters it uses. It will always end up as a fixed length hex string.
Labels:
security
Jun 6, 2009
Secure Exception Handling
Exception handling is an important part of building a secure application. Developers are often asked to pay close attention to the security context in which the exception handler executes as to ensure maximum robustness, both from performance and security point of view, of the application. The reason I mention this is a little ATM incident yesterday where a friend's debit card was swallowed in the middle of a transaction by the ATM. As my buddy provided his bank card, PIN, and withdrawal request, the ATM decided to crash -- resulting in a big red screen stating that the machine was out of order. After 3-4 minutes, while my friend was in touch with the bank's customer service, the machine restarted and started working as expected.
So what happened?
Based on the above observations it seems that the generic exception handler used in the ATM machine tells the machine to void the transaction and keep the card. There's nothing wrong with that. In fact, this seems like the most secure way to fail an operation without knowing the exact causes of this failure. However, this is where the flaw in this ATM actually is -- the gap between the source of the exception and the exception handler is too big. It's so big that the handler that catches the exception doesn't know what to do with it. This is where robustness fails and legitimate customers get pissed off. :)
So what happened?
Based on the above observations it seems that the generic exception handler used in the ATM machine tells the machine to void the transaction and keep the card. There's nothing wrong with that. In fact, this seems like the most secure way to fail an operation without knowing the exact causes of this failure. However, this is where the flaw in this ATM actually is -- the gap between the source of the exception and the exception handler is too big. It's so big that the handler that catches the exception doesn't know what to do with it. This is where robustness fails and legitimate customers get pissed off. :)
Labels:
daily life,
security
Subscribe to:
Posts (Atom)
