You are currently browsing the tag archive for the ‘talk’ tag.
Ill have a longer discussion of SIRACon later, maybe, but for now, you can find my talk slides here:
Some of it is old material, but some of it is new. I really like how it’s fitted together and ordered here.
So, with what is quite interesting timing, (and thanks, in no small part to Twitter), I just found out a couple of days ago that I’ll be giving a talk at EnergySec This year. The tentative title is: “A Technologist’s Admission of Inadequacy: The executive’s role in National Cyber Security”.
I’d really like to use this opportunity as a platform for some of my concerns, as a technologist, about how we’re treating cyber security as a technical problem – at an operational level, at a strategic business level, and at a legislative level. I’ve touched on these concerns before in this blog, but I’m really excited about the chance to do it in person in front of a lot of other smart people who are actively working cyber security problems.
Thinking out loud, I wrote this earlier:
One of my interests, part of my future role, and with a perspective grounded in building/designing ways to detect badness / working on ICS-CERT, is in combating our habit of defining security in technical terms or on relying on technologists to “fix it”without ever defining what “it” is. A secure system is one that does no more and no less than the people who have ownership and stake in it wish it to do- and that’s a business rule/decision/appetite. As a technologist, if you ask me to secure your systems and let me define what that means, I’ll fail. (ie: There is no “evil” flag in TCP). I’d like to make a plea for organizations to define security through risks to interrelated cross-sector business and social requirements (and associated appetites) before spending so much effort to create technical security plans, standards, controls, laws. An army without a defined mission can be potent just based on size and power, but one that has a mission and defined goals is much, much better.
I’m sure I’ll evolve what I actually want to say between now and September, but that’s where my head is now.
All, I’ll be giving a quick (5 minute) introduction to using Neurosky’s Mindset API to do cool stuff with your brainwaves – like making art while you sleep :) – on 02/23/10 @7:30pm as part of HacDC’s Lightning Talks (featuring 12 speakers for 5 minutes each). For the introduction, I’ll be using the simple Objective-C server and custom written Quartz Composer plug-in client to display a visualization that response to both your brainwaves and ambient noise/music together. Come out and see!
Check out the example proof-of-code video I did below (a longer post to come tomorrow):
So I was sitting in a critical infrastructure cyber security talk earlier this week and had a small revelation. The talk itself wasn’t all that interesting – it was another attempt to collect and identify consensus best practices for critical infrastructure security from a governance point of view – but it still led me down a path that surprised me.
The authors of the paper being presented had done interviews and other research and derived a number of principles required for critical infrastructure cyber security governance based on what they commonly heard over and over. At the talk, we had break-out sessions where they were pinging us for our thoughts on their findings. During the session, I realized that I’d heard it all before (obviously, right? It’s a consensus paper) and was wondering why we couldn’t get past the stale “wisdom” repeated ad nauseam without effect…when it hit me: the use of their paper might be directly opposite of what they might think it is, but it’s still useful!
The thought process is as follows:
- Assumption: We all “agree” that cybersecurity for critical infrastructure is insufficient and we’re missing something.
- Assumption: The paper represented the community opinion, to date, on what needs to happen for good cyber security
- People are trying to improve security, but despite sporadic improvements, we haven’t made nearly as much progress as we think we should. Something is missing.
Conclusion: Whatever it is we need to do …..isn’t in that paper. If we collect a series of best practices and community consensus on a topic where we generally consider ourselves to have failed, collecting that consensus should be used – instead of as a driver of activity – a hint at what won’t, by itself, get us where we need to be. The lists should be considered things to exclude as solutions to our unidentified sticking points, but the solutions themselves.