War Games II. This time it's Matthew Broderick against a whole city full of trained Chinese hackers.
http://online.wsj.com/article/SB10001424052702304563104576361300123816450.html?mod=WSJ_hp_LEFTTopStories
Thursday, June 2, 2011
Tuesday, May 31, 2011
OWASP San Diego: Jeremiah Grossman To Present on 6/14
The Open Web Application Security Project (OWASP) Chapter in San Diego is holding a meeting to discuss the latest developments in the OWASP organization and new ideas in leading-edge secure web development. Join us in welcoming Jeremiah Grossman to present details of the many notable and new web hacking techniques revealed in 2010, as well as some of the prevalent security issues emerging in 2011. Attendees will be treated to a step-by-step guided tour of the newest threats targeting today's corporate websites and enterprise users. Enjoy Sushi and Sake refreshments from our friends at Whitehat Security as you network with some of the best security auditors, researchers, and developers in the San Diego area. We look forward to seeing you there!
Date: June 14th, 2011
Time: 6:00pm - 8:00pm
Location: 10240 Sorrento Valley Rd
San Diego, California 92121
Please RSVP: rsvp@owasp-sd.org
858-754-9701
About OWASP:
The Open Web Application Security Project (OWASP.ORG) is a non-profit community devoted to improving focus on application security. OWASP continues to grow and deliver exceptional resources to security conscious individuals who are required to make informed decisions about true application security risks. A plethora of funded open-source products, new coding principals that have been adopted by PCI standards, and a unique list of involved security professionals make OWASP an invaluable forum to attend.
Date: June 14th, 2011
Time: 6:00pm - 8:00pm
Location: 10240 Sorrento Valley Rd
San Diego, California 92121
Please RSVP: rsvp@owasp-sd.org
858-754-9701
About OWASP:
The Open Web Application Security Project (OWASP.ORG) is a non-profit community devoted to improving focus on application security. OWASP continues to grow and deliver exceptional resources to security conscious individuals who are required to make informed decisions about true application security risks. A plethora of funded open-source products, new coding principals that have been adopted by PCI standards, and a unique list of involved security professionals make OWASP an invaluable forum to attend.
Sunday, March 20, 2011
RSA: Who is the doctor's doctor?
[caption id="attachment_150" align="alignnone" width="348" caption="Some solid security logic."]
[/caption]
It's pretty clear at this point that there's a trending of attacks focused on security solution providers. The most recent victim in the post-HBGary landscape is RSA.
A lot of people seem to be talking about what they believe actually happened during the breach. The company has yet to officially comment on the details of the incident and seems to be wordsmithing any communication to the outside world pretty heavily. While I'm sure the technical facts will be interesting, and that they will make their way around the rumor mill eventually, I'd like to talk instead about something that I feel is more important - due and reciprocal care.
The medical industry seems to have this concept pretty well wrapped up. If you ask a psychologist, "who listens to your problems?" they will tell you that their psychologist does. This is because it is considered unprofessional, and in some cases a violation of ethics code to self-diagnose, self-prescribe, and self-medicate. Of course, this begs the question of who treats the psychologist that treated the first psychologist? Well, another psychologist of course. So, theoretically, as long as there are at least 3 physicians in the world who practice psychology, this model will continue to function, and we won't end up with a bunch of mentally disturbed psychologists.
I doubt anyone on the professional services end of the information security industry would argue that there's a shortage of proprietors offering security assessment and remediation. So then why do things like the RSA incident happen? It's because nobody is examining the physician. In fact, I'd be willing to bet that if you took a sample set of posture assessments from top 10 information security product and service vendors, the results of what's already left the building would be staggering. Further, most people close to the steam will tell you that things have not changed dramatically from the days when the entire Solaris source tree was essentially public domain in the hacker underground, and Larry Ellison's personal passwords were in a t-file.
Why? It's simple. Just because your company's primary business is security does not mean that you possess said security. What it does mean, however is that the risk you take is not only limited your standard business risk, but that your reputation is predicated on your ability to protect own your assets in the same manner that you would help the customer protect theirs.
So that you don't think we're calling the kettle black, we have in fact engaged an outside advisor to look at the company footprint, assess security, and make recommendations for remediation. If you're a security vendor, shouldn't you?
[/caption]It's pretty clear at this point that there's a trending of attacks focused on security solution providers. The most recent victim in the post-HBGary landscape is RSA.
A lot of people seem to be talking about what they believe actually happened during the breach. The company has yet to officially comment on the details of the incident and seems to be wordsmithing any communication to the outside world pretty heavily. While I'm sure the technical facts will be interesting, and that they will make their way around the rumor mill eventually, I'd like to talk instead about something that I feel is more important - due and reciprocal care.
The medical industry seems to have this concept pretty well wrapped up. If you ask a psychologist, "who listens to your problems?" they will tell you that their psychologist does. This is because it is considered unprofessional, and in some cases a violation of ethics code to self-diagnose, self-prescribe, and self-medicate. Of course, this begs the question of who treats the psychologist that treated the first psychologist? Well, another psychologist of course. So, theoretically, as long as there are at least 3 physicians in the world who practice psychology, this model will continue to function, and we won't end up with a bunch of mentally disturbed psychologists.
I doubt anyone on the professional services end of the information security industry would argue that there's a shortage of proprietors offering security assessment and remediation. So then why do things like the RSA incident happen? It's because nobody is examining the physician. In fact, I'd be willing to bet that if you took a sample set of posture assessments from top 10 information security product and service vendors, the results of what's already left the building would be staggering. Further, most people close to the steam will tell you that things have not changed dramatically from the days when the entire Solaris source tree was essentially public domain in the hacker underground, and Larry Ellison's personal passwords were in a t-file.
Why? It's simple. Just because your company's primary business is security does not mean that you possess said security. What it does mean, however is that the risk you take is not only limited your standard business risk, but that your reputation is predicated on your ability to protect own your assets in the same manner that you would help the customer protect theirs.
So that you don't think we're calling the kettle black, we have in fact engaged an outside advisor to look at the company footprint, assess security, and make recommendations for remediation. If you're a security vendor, shouldn't you?
Monday, May 10, 2010
The Final Word on Hiring Hackers.
I'm addressing this about 6 months too late, but there was an extremely repetitive, relatively ignorant article that was written by M. E. Kabay which rehashes the topic of whether or not you should hire hackers for what seems to be the hundredth time. There are additional comments on Brad Johnson's blog here: http://systemexperts.blogspot.com/2009/10/hiring-hackers-please-dont-by-brad.html
The only people who argue against hiring hackers are people who are riding their coat tails, or trying to create controversy that simply isn't there. Put simply, the information security industry was -created- by the very hackers that the article suggests you shouldn't trust. The concept of compliance regimes, security standards, controls, and technologies like firewalls, IDS/IPS, DLP, etc... wouldn't exist without the need for security, and the need for security is addressed by these companies... right... the ones created by hackers.
In fact, suggesting that you shouldn't ever hire a hacker to work on your security project is analogous to suggesting that a doctor who has performed exploratory surgery on a patient with success is somehow less qualified to address your ailment.
Chris and Al, both of whom I have seen own various parts of our nation's infrastructure first hand, are two of the most respected early security technology executives in the industry. Maybe you've heard of their companies: Secure Networks, and ISS. Sorry guys, you're outed. It's been like 20 years, so I'm pretty sure you're safe from a statutes perspective. Point being that hackers are the primary people who are responsible for you having an industry to work in.
Its just funny to me that people are still having this conversation, because the argument that no one should hire hackers is silly. If you want to buy a product or have a service executed that even remotely involves security, you WILL be hiring a hacker, and you don't really have a choice in the matter. If you end up with zero hacker involvement, you may want to review the efficacy of the product or service you just bought.
Wednesday, January 20, 2010
OWASP Hacking Dojo - Sushi, Sake, Security
San Diego OWASP is having a FREE sushi, sake, and hacking workshop on January 27th at 6:00pm. Hope to see you all there.
Monday, October 12, 2009
Cloud Security is the New Hoverboard
You might not remember the whole thing about hoverboards and the "behind the scenes" footage from Back to the Future - Part II, but I do. There was this producer or director or some other sort of executive in charge of the movie, and he calmly explained that the hoverboard in the movie was in fact real. He then went on to explain in elaborate detail how it would soon be available in stores all over the US.
Not a hint of sarcasm, no jesting facial expressions. This guy was dead serious.
I know this because I was 14 at the time, and I swore that I would have one for my birthday. My buddy Eric was even hinting that he thought his mom had picked one up and stashed it away for Christmas already, fearing that they would sell out.
Well, as i'm sure you've already guessed, the joke's on Eric and I, because there is no hoverboard. Never has been... probably never will be.
This is why I want to talk to you about "cloud security." Now, I'm not implying that you're 14 and gullible, but there are actual people out there who believe in this thing, and if you're one of them, then you might also start examining why you started adding "ph" to everything that formerly started with an "f" in infosec, right about the same time everyone else did. Actual hackers stopped doing this in the early 90s. The industry started doing it in about 2003.
Scientifically speaking, there's no way that cloud security can exist, because it has a dependency on "the cloud," which I have yet to locate.
Do you know why the cloud cannot exist? because for something to be relevant nomenclature in technology, it needs to be something that has a net positive or negative effect on either most companies or most consumers. The cloud doesn't matter, and I can prove it. Do this:
1. The name of your company is ______(A)________.
2. You currently rely on "the cloud" and the security of the cloud for _____B_____, ______C______, and _____D______.
3. The market space you are in is ________E_______.
4. A security technology that is cloud specific is: _______F________.
4. Assemble the following sentence:
Not a hint of sarcasm, no jesting facial expressions. This guy was dead serious.
I know this because I was 14 at the time, and I swore that I would have one for my birthday. My buddy Eric was even hinting that he thought his mom had picked one up and stashed it away for Christmas already, fearing that they would sell out.
Well, as i'm sure you've already guessed, the joke's on Eric and I, because there is no hoverboard. Never has been... probably never will be.
This is why I want to talk to you about "cloud security." Now, I'm not implying that you're 14 and gullible, but there are actual people out there who believe in this thing, and if you're one of them, then you might also start examining why you started adding "ph" to everything that formerly started with an "f" in infosec, right about the same time everyone else did. Actual hackers stopped doing this in the early 90s. The industry started doing it in about 2003.
Scientifically speaking, there's no way that cloud security can exist, because it has a dependency on "the cloud," which I have yet to locate.
Do you know why the cloud cannot exist? because for something to be relevant nomenclature in technology, it needs to be something that has a net positive or negative effect on either most companies or most consumers. The cloud doesn't matter, and I can prove it. Do this:
1. The name of your company is ______(A)________.
2. You currently rely on "the cloud" and the security of the cloud for _____B_____, ______C______, and _____D______.
3. The market space you are in is ________E_______.
4. A security technology that is cloud specific is: _______F________.
4. Assemble the following sentence:
Since i've been at ______A______, our ________B________ , ________C_______, and ______D_______ have enabled the company to improve bottom line, increase productivity, and set an example in the _______E_______ industry, showing that obviously, we're still a market leader, and that cloud computing has changed the way we do business, forever. Also, I try to stay childlike by perpetuating my belief in the existence of ______F_______.
Wednesday, September 23, 2009
First Data and RSA to Provide Tokenized Card Processing
As you know, I pretty much constantly complain that noone ever does anything to inherently make better the state of data security when it comes to credit cards. The brands are always blame shifting, and merchants get left holding the liability bag and paying for everything.
Well, I'm not going to suggest that First Data has solved all of these problems, but what I will say is that I think they've put a stake in the ground with this new service. Their new, "Secure Transaction Management" service utilizes RSA's tokenization technology on the endpoints to minimize the usage of credit card data throughout the enterprise. Partnering with RSA on this product gives some credence to it. Merchants aren't inclined to trust a payment processor who makes claims about the security of a technology unless a trusted 3rd party gets involved and makes it so.
This obviously isn't my Utopian solution. I think card data needs to be public key exchange based, starting on the card. I realize that this makes me some sort of fringe lunatic thinker. However, given that wholesale changes at Visa aren't likely, First Data's STM seems like a pretty good idea.
The only concerning part of the press release was this:
"The service uses First Data infrastructure by storing credit card data in secure servers for future retrieval by the merchant if necessary, while returning tokens to the merchant for use in their systems, Capellas said."
There's still a certain amount of faith that this product places in the merchant to determine what is "necessary." People like to store things that they're not supposed to, and making the data available to them practically guarantees that they'll find a way to use it inappropriately.
That said, this is the first time I've seen a payment processor take an active roll in providing a product which has a security provision layer as a core part of the offering. Nice work guys.
One piece of advice:
keep an eye on those "secure servers" that store data for "future retrieval."
Well, I'm not going to suggest that First Data has solved all of these problems, but what I will say is that I think they've put a stake in the ground with this new service. Their new, "Secure Transaction Management" service utilizes RSA's tokenization technology on the endpoints to minimize the usage of credit card data throughout the enterprise. Partnering with RSA on this product gives some credence to it. Merchants aren't inclined to trust a payment processor who makes claims about the security of a technology unless a trusted 3rd party gets involved and makes it so.
This obviously isn't my Utopian solution. I think card data needs to be public key exchange based, starting on the card. I realize that this makes me some sort of fringe lunatic thinker. However, given that wholesale changes at Visa aren't likely, First Data's STM seems like a pretty good idea.
The only concerning part of the press release was this:
"The service uses First Data infrastructure by storing credit card data in secure servers for future retrieval by the merchant if necessary, while returning tokens to the merchant for use in their systems, Capellas said."
There's still a certain amount of faith that this product places in the merchant to determine what is "necessary." People like to store things that they're not supposed to, and making the data available to them practically guarantees that they'll find a way to use it inappropriately.
That said, this is the first time I've seen a payment processor take an active roll in providing a product which has a security provision layer as a core part of the offering. Nice work guys.
One piece of advice:
keep an eye on those "secure servers" that store data for "future retrieval."
Subscribe to:
Posts (Atom)