<![CDATA[[SecurityRatty] tag: avoidable]]> http://securityratty.com/tag/avoidable Sun, 16 Sep 2007 08:35:00 +0000 iRatty Engine http://blogs.law.harvard.edu/tech/rss <![CDATA[SSO Summit Day One Morning Session]]> http://securityratty.com/article/500327e2eca382c04451c330dcc1e875 http://securityratty.com/article/500327e2eca382c04451c330dcc1e875 I am at the SSO Summit, high in the Colorado mountains (9200 feet elevation to be exact), the I-70 West sign is one of my favorite road signs. Ping Identity has done a great job putting this together. It is the perfect size around 125 people. Most of the best conferences I have been to have been around 60-150 people. There are a *lot* of enterprises involved here. 
John Haggard who has an extensive background in SSO and lately is at Passfaces kicked off the sessions with a SSO history talk. Going through a lot of mainframe centric SSO protocols from the 80s and 90s, I am no expert in these areas and it was fascinating to see the way things vacillated between strength and weakness of SSO protocols.

A couple of points from the presentation:

The history of SSO is a story of extreme complexities, compromises, vulnerabilities and unintended consequences.


SSO is a story of one simple objective - to spin off units of computation work to execute on behalf of an authenticated user without requiring the original user's password.


Phishing has always been completely avoidable


He went through the various incarnations of mainframe SSO from logon id through things like ACF2, VTAM Session managers, terminal emulators, multiplatform access to web access through facades. The implication he drew from this last step are well worth repeating: "Time to rethink everything." Problem is - of course, people don't rethink, they put MQ Series in front of the mainframe and hook a web app in front of that and go. 

Finally, he connected some interesting dots to SAML and SOA security issues. 

SSO without strong auth is and always will be simply nuts


SAML gets its right

His points around common weaknesses in integration in SOA and Web 2.0 technologies for companies that are *not* using SAML were excellent. Of course, I will go into some more details on this tomorrow.

Ping's CTO Patrick Harding took the stage and gave an overview of the next generation of SSO options from Kerberos to present and as is his wont demonstrated various real world strengths and weaknesses, quoted a Gartner analyst (shock!) saying OpenID is the hare and Cardspace is the tortoise. Nice.

Andrew Cameron from GM is speaking now on GM's experiences implementing SSO, and there are a lot of real world lessons learned in his presentation.  Plus my favorite identity architecture, user has Kerberos, services speak SAML. very nice, very scalable. All in all, its my starting point for how to identity in an enterprise. He also spoke about a pet peeve of mine - how to globalize authorization. This is not a problem that vendors have historically attacked with relish. They are very happy to help you solve authentication, but they are perfectly happy to keep their authorization internal either for vendor lock in reasons and/or for sloppy authorization design. This will take a LIberty-esque consortium of enterprises to resolve. 

So many conferences are dominated by vendors and consultants who conspire to what I call the "sacred church of things YOU should be doing." Instead this conference is bringing together a great mix of real world in the trenches practitioners who have problems to solve today, with rubber meets the road deployable solutions and an eye towards longer term strategy for SSO and identity.
]]> Thu, 24 Jul 2008 09:35:02 +0000 sso sso history talk sso summit mainframe sso sso options sso protocols real world real world lessons authorization internal SSO Summit Day One Morning Session <![CDATA[Can you hear me now?]]> http://securityratty.com/article/afde45737ad0a9346c45bdf544337ad3 http://securityratty.com/article/afde45737ad0a9346c45bdf544337ad3 Verizon released a very interesting Data Breach report that analyzes over 500 forensic reports on their system over a number of years. It is great work by Verizon to gather this data and to publish it. Of course a consultant I go into lots of companies where they could learn a lot just by being more open and talking through issues with peers in other companies. Would be great to see other companies follow Verizon's lead.


I suggest you read their report, and I would like to add a little color to their findings from the perspective of the swamp I spend most of my time in - Web services security. Granted it is just one report, but the data run counter to a lot of conventional security "wisdom":

Who is behind data breaches? 

73% resulted from external sources
18% were caused by insiders 
39% implicated business partners 
30% involved multiple parties


The internal/external divide is pretty silly these days, as is companies' recanting "inside the firewall and outside the firewall", I spend most of time hooking things up together precisely _so_ they intereoperate remotely. The firewall is a speed bump at best. At any rate external sources is a primary concern in Web services security, because - hey look our Web service front end just made your Mainframe/As400/Unix DB/ CICS/whatever accessible remotely. This is great from a functionality standpoint, but the issue is that these back end systems were never designed with anything remotely resembling an Internet threat model. Additionally, the Verizon team's findings around business parties and multiple parties strikes at the heart of a number of popular misconceptions in Web services security - "well its just B2B and its behind a firewall."


How do breaches occur? 


62% were attributed to a significant error

59% resulted from hacking and intrusions  

31% incorporated malicious code 

22% exploited a vulnerability 
15% were due to physical threats 


A couple of things to note here - malicious code in my opinion is likely to be the biggest problem in Web services security going forward. There is a large gap waiting to be exploited here. You have no control over the other end of the pipe plus a massive attack surface, the only thing lacking is the attacker's ability to find and exploit which I strongly suspect is just a matter of time. Wrt hacking an intrusions we have the remote, passive nature of web security to blame here in Web services world. Paraphrasing Jeff Williams, the problem is that an attacker can just try an attack if it doesn't work, try again, again, and so on. This partially because of the loosely coupled nature of the systems, but it is also because commonly used information security protocols have diverged from reality are modeled using an object-centric mentality, where you "own" the object you are protecting and can afford to put passive controls around.

What commonalities exist? 


66%  involved data the victim did not know was on the system
75%  of breaches were not discovered by the victim  
83%  of attacks were not highly difficult 
85%  of breaches were the result of opportunistic attacks 
87%  were considered avoidable through reasonable controls 

Many of the attacks against Web Services are not difficult, in my training class, we'll typically execute 8-10 different attacks in a two day period. But the big one from this list is the first one - the amazing amount of attack surface offered up by Web services. Brad Hill has done a good job articulating these issues in SOAP/XML/WS-*, but at an enterprise its even bigger than those standards - the thing is we use Web services to make stuff interoperate, to make stuff reusable, and to virtualize endpoints. Great stuff if what you want to do is decentralize your business, but this creates oceans of space for attackers to roam. When you look beyond the Visio and the IDE view of web services, and get to the runtime there is an amazing amount of detritus left behind by all these layers.



]]> Fri, 27 Jun 2008 06:56:10 +0000 web services web services world web services security data breach report report attack massive attack surface companies follow verizon data Can you hear me now? <![CDATA[Maryland Department of Assessments & Taxation web exposure]]> http://securityratty.com/article/9559cb5894838514ec333efe928d6996 http://securityratty.com/article/9559cb5894838514ec333efe928d6996 Security Breach

Date Reported:
1/4/08

Organization:
State of Maryland

Contractor/Consultant/Branch:
Department of Assessments and Taxation
Towson University's Regional Economic Studies Institute

Victims:
Maryland residents applying for a homestead tax credit

Number Affected:
Unknown*

*roughly 900 people used the system on the day in question.

Types of Data:
Names, addresses and Social Security numbers

Breach Description:
A web application used to collect information from residents over the internet was not adequately secured with encryption leaving some sensitive personal information un-protected while transferred from clients to the Web server.

Reference URL:
Washington Times News Story

Report Credit:
Gary Emerling, The Washington Times

Response:
From the online source cited above:

Officials said residents applying Monday for the homestead-tax credit at the Maryland Department of Assessments and Taxation Web site (www.dat.state.md.us) may have exposed their Social Security numbers online because the application system did not have a necessary security certificate to encrypt the information before it was sent out over the Internet.

Robert Young, the department's associate director of assessments and taxation, said the gap briefly left the numbers exposed, but the information was transferred to a secure server after an application was submitted.
[Evan] Let's hope that the "secure server" is actually secure.  This breach would not have occurred if proper security testing were carried out prior to production.  If the site itself had not been properly tested, should we assume that the secure server had/has been.

"For that minute or so there ... that wasn't encrypted," Mr. Young said. "If they submitted an application, it went to a different section that was encrypted."
[Evan] My interpretation is that the "secure server" encrypts the information and it is stored encrypted.  If so, then good work!  Although, I could be wrong.

The application system on the site went online Dec. 28 but was not accessed until Monday, after residents had received their assessment notices in the mail. Roughly 900 people used the system that day.

Mr. Young said it would have been nearly impossible for anyone to access the numbers because of the brief amount of time they were exposed and because hackers would have had to tap into Internet transmission lines from a specific location.
[Evan] Not nearly impossible.

"Somebody would have had to been focused in on that site," Mr. Young said. "The chances of that are virtually nil."
[Evan] I do agree that the risk is relatively low, I do not agree that an attacker would have to have "been focused in on that site" in order to capture the information.

Tim Brooks, the institute's associate director in charge of software development, said a hacker would have had to be located right outside the home of a resident accessing the site or outside of the institute's data center at Towson to steal the numbers once they were sent out over the Internet.
[Evan] This is not true.  A successful compromise of the data transmission could take place at any point between the resident's computer and the server itself.  This would include anywhere between a resident's computer and the resident's internet access point (usually a router), the resident's access point and all traversed points within the resident's internet service provider's (ISP) network, between the resident's ISP and any other traversed points within any other internet network provider on the way to the State of Maryland's ISP, all traversed points within the State of Maryland's ISP, and all traversed points within the Maryland network until it reached the web application server.  The risk of compromised between all of these points is still relatively low, but it is unnecessary risk nonetheless.

"While it is technically possible there was some sort of compromise, it is logistically unfeasible," Mr. Brooks said.
[Evan] It is logistically infeasible for a single attacker to capture all of the information sent in the clear.

officials shut down the site on Monday at about 4 p.m. and added the extra protection. The site reopened Wednesday at about 4:15 p.m. and is now secure.

Commentary:
Maybe you read the information about this breach differently, but to me it seems that someone forgot to configure encryption (i.e. http vs. https) for the data in transit to the State of Maryland's web site that was collecting sensitive information. 

Althought, I agree with the officials that claim the risk of exposure to resident's personal information is low, it was such an easily avoidable risk.  The amount of risk would have risen with the amount of time that the vulnerability existed.  Web applications, especially e-commerce shopping carts and others that collect confidential information, must be thoroughly tested by knowledgeable information security personnel prior to production.  More than anything else, this breach causes unneeded embarrassment for the State of Maryland and perhaps provides insight into software development practices as it related to information security.

On semi-related note, according to a story posted on the Louisville, Kentucky Courier Journal claims that "A 15-minute search on the Maryland Department of Assessments and Taxation Web site found Social Security numbers on statements filed by creditors who had financed purchases by four consumers in Waldorf, Cambridge, Bowie and Landover in 2003 and 2004."

Past Breaches:
August, 2007 - Stolen laptop from the Maryland Department of the Environment


]]> Sat, 05 Jan 2008 11:02:15 +0000 maryland sensitive personal information personal information secure server hadhas server web application server application information information security Maryland Department of Assessments & Taxation web exposure <![CDATA[Buffer Overflows are like Hospital-Acquired Infections?]]> http://securityratty.com/article/26aef2ec89f04f81dd974d961308b618 http://securityratty.com/article/26aef2ec89f04f81dd974d961308b618 piece about new policies being implemented related to "Avoidable Errors."

The idea is that certain medical outcomes are always the results of medical negligence rather than inherent issues in medicine such as patient differences, etc. A few things that fall into the avoidable category are:
  • Common hospital-acquired infections
    • Urinary tract infections for example are extremely rare when proper protocols are followed.
  • Blatant surgical errors
    • Tools left in patient for example. There are easy ways to make 100% sure this doesn't happen.
What is most interesting I think is that historically there have been problems with these issues, but we now have good procedures for avoiding these in almost circumstances. There will be corner cases as the article points out, but these are by far the exception.

For historical context we didn't used to understand that we needed to sterilize needs and/or use them only once. Needles used to be expensive and so we reused them, but we discovered infection rates were unacceptably high. We created low-cost disposable needles and we use those now instead because they are safer.

Similarly we continue to program in languages that make avoiding things like buffer overflows tricky. Not impossible, but tricky. Given the attention to buffer overflows, the fact that we have tools to completely eliminate them from regular code, I'd say they fall into the same category as surgical tools left inside the patient - negligence.

A key quote from Lucien Leape of the Harvard School of Public Health:

Today, he says, dozens of safe practices have been developed to prevent such errors. But he says there hasn't been enough of a push for hospitals to put them into use.

"I think it's fair to say that progress in patient safety up to now has relied on altruism. It's been largely accomplished by good people trying to do the right thing," Leape says. "And what we're saying is that hasn't gotten us far enough, and now we'll go to what really moves things in our society, which is money."

Maybe I should start putting money-back guarantees in my contracts with software vendors so they owe me a partial refund for every buffer overflow that gets exploited/announced in their code?]]> Sun, 16 Sep 2007 08:35:00 +0000 buffer overflows infections patient buffer overflows tricky errors patient differences avoidable errors tricky blatant surgical errors Buffer Overflows are like Hospital-Acquired Infections?