You are currently browsing the tag archive for the ‘security’ tag.
Say you want to buy a car to take your 5 kids and spouse around town. Now, suppose you start looking for a good, safe van with low gas mileage that fits the whole family and is relatively cheap. $20k? sure. Ok, now what if you go out to buy this van….but oh no! All you can find are corvette dealers selling $100,000 cars!!!
Would you buy a corvette? Hells no. You’d wait until you found something that met your minimum requirements: Moving the family around. If you got the vette, you would have gotten something that, even if it fit “some” of your requirements (moving some people around), doesn’t fit enough of them to actually solve the problem. Furthermore, if you did get the vette, you probably wouldnt be able to afford the van so your problem would go on even longer than if you hadnt gotten the corvette.
Welcome to the kind of security that says “we should do more of what we’ve been doing, even though we know the architectures don’t work…because something is better than nothing.“ We can’t continue to add on layer after layer of security at ever increasing cost when no number of those layers, as modeled today, will ever get us to a comfortable place. Getting owned by X% fewer people is still getting owned and doesn’t really change your risk profile unless X is a much bigger number than today’s most common best practices get us.
Nothing is ever perfect, so I’m not suggesting no one should take action until they find a perfect solution. Rather, I’m suggesting we all take a close look at our solution sets and look at how good they’re ever going to get at the end of the day and make decisions appropriately. When selecting a “50%” solution architecture for $Y, dont get caught thinking $Yx2 will get you a 100% solution with the same architecture:)
I normally don’t have much to say here about my day job (partly why you’ve seen more of a focus on art), but I thought (since I’d been previously linking to the DHS Control Systems Security Program pages) that it was worth mentioning that ICS-CERT has its own website these days: http://ics-cert.org
Take a look at it if you’re in the control systems / SCADA and security/emergency space (particularly with regard, but not limited, to cyber).
Edit/Update: Now that I’m no longer there, I do have a brief take on the subject and a summary of information HERE
I’ve created a google code page for it HERE.
You can grab a stand alone zip of the source/project HERE.
(I’ve never used SVN before, so what’s up at the google code page might periodically be fubared, so you might want to start with the zip)
Feel free to download, comment, and please -contribute-. This was my first Objective-C app and first Xcode project, so if it’s a mess…well…deal or help? :)
Just remember the google code page if you want to post some updates or questions.
I’ve also made some haphazard notes to help people understand the code:
The aquireData class handles reading the tcpdump text file. It uses Core Data to store the data. If I had to do it over, I wouldn’t have used Core Data…but it is what it is. You can find the data model by double-clicking pkviz_DataModel under the Models folder in the project in Xcode.
pkGraphView is a subclass of NSView that I use to handle the layers, which are done in Core Animation (easy enough to understand). The view has a delegate function (drawLayer) which I handle in the layerDelegate class to deal with drawing the paths for each layer.
Everything else is handled by transformData – it’s pretty much my controller.
the Load button tells aquireData to parse tcpdump and store in a core data context
The launch button kicks off transform data, which pulls in the data from the core data context, sticks it into an array, launches a thread to pop out individual packets, and then tells the view when it’s read to display another packet. Everything else stops, starts, adjusts the current packet referenced, or aids this animation loop process.
The main array of packets in transformData is bytepakposSet. It is an array of packet arrays. packet arrays contain arrays of bytes with 2 values in them: bytevalue, and byteposition
so, if you wanted to access the third packet in bytepakposSet and see what the byte value of the first byte stored is, you’d do:
[[[[bytepakposSet objectAtIndex:2] objectAtIndex:0] objectAtIndex:0] intValue];
if you wanted to get the byte value and position returned in an array:
[[bytepakposSet objectAtIndex:2] objectAtIndex:0]
Core Data doesnt return objects in order, so you dont know ahead of time what order the bytes are in the packet, youll have to sort them by position in packet first. You can find position:
[[[[bytepakposSet objectAtIndex:2] objectAtIndex:0] objectAtIndex:1] intValue];
In a bit of fun and interesting timing it turns out I’ll be going to flocon in New Orleans this January.
Since I’ve spent the past 2-3 years doing business risk and security architecture, national sector level strategy, policy, etc….but now find myself getting into the technical details of building a CERT (ICS-CERT, specifically)…it’s suddenly time to get more up to speed on flows and how people are using them these days (Especially since I’d previously spent most of my time with firewalls and IDS data and not netflow / SiLK stuff).
My work on and release of pkviz this past weekend has helped a bit to get me re-focused on data analysis and playing with correlation tools and methodologies, but I’m still finding it odd going back to my earlier technology-centric security role – which I’d thought I’d given up. My head space has to be completely different than it was and I have to work around what some have called my fatalistic belief that technical security measures and analysis are doomed to fail in the face of our complete lack of interest in doing business risk architectures.
What scares me a little, though, is when I’ve been talking to people and doing research lately, it seems the state of the art of IDS, Flows, SEMS, SIEMS, network data analysis, etc. hasn’t changed all that much in the past few years. More vendors have sold more products, but they still do the same (questionable) things it seems. What gives? Am I off base?
Still, I’m pretty excited to get back into this type of thing and about the con. Who’s going to be there?
I just wanted to make sure everyone remembers to register for this great conference in DC this year. From their website:
Press Release August 20th 2009 — Speaker Agenda Released and Registration Open!
We are pleased to announce that the OWASP DC chapter will host the OWASP AppSec 2009 conference in Washington, DC. The AppSec DC OWASP Conference will be a premier gathering of Information Security leaders. Executives from Fortune 500 firms along with technical thought leaders such as security architects and lead developers will be traveling to hear the cutting-edge ideas presented by Information Security’s top talent. OWASP events attract a worldwide audience interested in “what’s next”. The conference is expected to draw 600-700 technologists from Government, Financial Services, Media, Pharmaceuticals, Healthcare, Technology, and many other verticals.
AppSec DC 2009 will be held at the Walter E. Washington Convention Center (801 Mount Vernon Place NW Washington, DC 20001) on November 10th through 13th 2009.
Who Should Attend AppSec DC 2009:
- Application Developers
- Application Testers and Quality Assurance
- Application Project Management and Staff
- Chief Information Officers, Chief Information Security Officers, Chief Technology Officers, Deputies, Associates and Staff
- Chief Financial Officers, Auditors, and Staff Responsible for IT Security Oversight and Compliance
- Security Managers and Staff
- Executives, Managers, and Staff Responsible for IT Security Governance
- IT Professionals Interesting in Improving IT Security
This is a repost of my recent comments on SCADASEC with regard to the most recent rush of frantic reports of cyber-espionage and the subsequent pitchfork-waving demands for legislation and/or further immediate regulation.
Ok, so bad stuff is happening. Whether or not we agree on the extent, damage, or origins of attacks against our infrastructure, there’s no disagreement among people in the industry that there is a problem that must be dealt with. So, now that we’re here, let’s all take a breath and look around and assess where we’re at.
First, these intrusions do not seem to represent a substantial change in our tactical situation; these types of intrusions have been occurring in one form or another for years. We may be -detecting- them more frequently before, but that’s it. A nationally significant incident occurring by way of a cyber attack against our critical infrastructure by a serious actor is, by many accounts, just as likely to happen now as it was a few years ago. This is interesting. It has long been observed that “the internet can be taken down in 30 minutes and no one is sure why that hasn’t happened yet.” I imagine that a similar thing can be said about our critical infrastructure.
While I am not suggesting that there is anything but a pressing, critical, national security level issue with the state of our cyber security and CIKR, I am suggesting that it is not so imminent that the value of taking our considered time in fixing the problem should be thrown out in favor of passing rushed, ill-advised legislation or regulation.
Let me elaborate:
The proposed cyber security / critical infrastructure regulation proposals I have seen would absolutely achieve a short term tactical gain in our level of security.
It would do so, though, by committing us to a permanent cyber security arms race at the cost of any hope of a long term strategic win. We would spend all of our money, effort, and cycles, repeatedly reacting to our adversaries’ change in tactics and would provide no method of ultimately getting ahead of them. Eventually, we would have 853 (heh) layers of defense, attackers would still be getting through them all, but we’d be out of any more money to throw at more layers.
This is both because of the nature of the problem as well as the proposed solution. What we have on our hands is a complete architectural failure of our cyber networks with regard to “security”. It is not the lack of some subset of individual security controls. Mandating specific control sets at this point – or any existing in-place “security best practices” – would be akin to insisting that contractors keep building a house on top of a known bad foundation. Incremental improvements will never address that kind of a problem.
What we need (from our technology) but do not have are information-centric systems with end-to-end processing requirements designed into their bones. We skip the hard work of identifying what information we need our systems to produce, what information they need to take in initially, what transformations must be made to the source information, and who can make those transformations in what contexts. We then fail to tightly couple our code, our designs, and our infrastructure to those requirements when we do have them.
We skip it because it seems hard and expensive and the perceived value of speed and the enticements of deferred costs seem to outweigh the risks to the organizations making these decisions. The costs of adding layers and layers and layers of ineffective security afterwords, however, is rarely calculated and compared to just doing it right the first time.
Instead of doing the right thing up front, we end up with tack-on solution sets like NIST 800-53. I don’t know about you all, but I’m pretty sure that if you did everything 800-53 describes – but never did the legwork I just described – security would still fail and it would fail badly. In fact, we see this time and time again in existing federal IT networks. 800-53, by itself, does not work for IT. Why would we legislate it for control systems? I don’t mean to pick on NIST here – it’s one of the better control catalogues out there – but that still doesn’t mean it works.
Technically, we are actually -nowhere near- industry agreement on how to solve the cyber security problem (Did anyone listen to Bruce Potter’s opening Shmoocon remarks? He astutely compared our current cyber security efforts to building a Maginot Line “In-depth”). If that’s true, then legislating something we know will never allow us to achieve a strategic win seems contrary to logic. But, if we want to put our heads in the sand and go the “any incremental gain we can achieve now is worth it even if we’ll have to redesign it from scratch later” route, the idea of legislating security controls for our critical infrastructure is still fatally flawed.
Why? Because a lack of security controls in our national critical infrastructure is not the problem, it is a symptom. Not only is it a symptom, but it’s a symptom of exactly the same problems that led to Wall Street’s collapse and the atrocious mortgage mess. Let me say that again: “it’s a symptom of exactly the same problems that led to Wall Street’s collapse and the atrocious mortgage mess.”
Those with budget authority – in both private and public organizations – are collectively and consistently making poor operational risk management decisions. They are opting for short term gains at the expense of long term strategic success. From where I sit, I honestly cannot tell whether it’s intentional or simply a lack of visibility into what the actual risks are (which stems from poorly designed organizational architecture). In either case, we have an issue of priorities by people making decisions – and that’s not a technical failure at all.
What happens if we mandate 800-53 or something similar? We create yet another technical compliance regime which, at best, only indirectly affects prioritization of cyber risk. The priority for decisions makers becomes meeting the regulation, not securing their organizations. When this happens, the risk is pushed down to the dedicated people on this list who then have to do the best they can in an environment where their organizations limit their ability to ultimately succeed. When that happens, we also find that good money is repeatedly thrown after bad and security, instead of being a business enabler, becomes a bottomless pit.
We need to find a way, if we think legislation is needed, to directly legislate cyber security as a priority and accountability for failure. If user information is stolen, decision makers need to be held responsible. If control systems are compromised in ways that could result in public harm, decisions makers need to be held responsible. If people suddenly became on the hook for -succeeding-, then one would hope the market and industry would be driven to finding ways to succeed.
It would be nice if education, not legislation, would suffice for this. But what I’ve been hearing on this list and in professional forums seems to indicate that the time for that is almost behind us. So, if we’re going to end up with legislation or regulation, let’s do it slowly, so it goes smoothly, so it’ll work quickly.