<![CDATA[[SecurityRatty] tag: muster]]> http://securityratty.com/tag/muster Thu, 04 Jan 2007 21:00:00 +0000 iRatty Engine http://blogs.law.harvard.edu/tech/rss <![CDATA[Network skill level gap is growing, but growth opportunities abound!]]> http://securityratty.com/article/a4929ca88458feb902376bc7bd38e824 http://securityratty.com/article/a4929ca88458feb902376bc7bd38e824 Test Quiz A recent IDC report sponsored by the Cisco Learning Institute reveals a huge networking skills gap is emerging in North America, which spells trouble for enterprises. Listen to this: “600,000 IT workers were needed to install, configure, manage and secure networks in North America in 2007, 14% of the total IT workforce.” However, IDC reports that another 180,000 engineers with wireless as well as traditional network engineering experience will need to be added by 2011 to keep pace with advances in technology that is transforming the role of the network.

The convergence of voice and video traffic are quickly transforming the growing complexity of networks at a torrid pace. IDC estimates that the skills gap in VOIP should grow to 19% by 2011.

This changing profile in the role of the network plays a key role in the skills shortage. Network enabled collaboration tools such as social networking apps and the Webex conferencing/collaboration solutions we use in our business each and every day are demanding a new set of IT skills to deliver business value.

My perspective is two-fold on this issue; the first is what I have seen in the resources we have attempted to hire! We give a very straightforward quick written/oral test to all new technical hires. This requires basic networking knowledge and some Unix commands. On average, (after filters from reputable recruiting firms, some with 5-10 years experience) less than 10% pass muster for the first filter we use in our hiring process. This is a troubling fact, which has cost us considerable time and effort to secure the right resources with competent skills. So I can say from our market assessment in a very strong technological job skills market, core Unix and networking foundation skills are slipping.

The second is that we as an IT Operations Management (ITOM) industry need to keep pushing hard to build better proactive and intuitive solutions to aggregate instrumentation from all Data Center tools, including more work around VOIP, video streaming, and collaboration so that we can ease this transition. If ITOM solutions become more proactive across the typical Cisco infrastructure that is commonly installed in the Data Center, we can free up some additional time for advanced “emerging technologies” training where existing IT workers can enhance their core skills and re-invigorate their careers. We have to do a much better job of getting our existing IT professionals trained on emerging technologies!

While there’s less that ScienceLogic can do around training, we certainly strive to do our part to enhance a day in the life of the networking engineers who use our solutions to simplify monitoring of increasingly complex networking, Wireless, VOIP, and collaboration needs.

]]> Mon, 25 Aug 2008 17:06:07 +0000 skills foundation skills network skills gap skills shortage intuitive solutions solutions traditional network recent idc report Network skill level gap is growing, but growth opportunities abound! <![CDATA[The War on Photography]]> http://securityratty.com/article/e6f171eea9c9a93417a3d9104f855e8e http://securityratty.com/article/e6f171eea9c9a93417a3d9104f855e8e What is it with photographers these days? Are they really all terrorists, or does everyone just think they are?

Since 9/11, there has been an increasing war on photography. Photographers have been harrassed, questioned, detained, arrested or worse, and declared to be unwelcome. We've been repeatedly told to watch out for photographers, especially suspicious ones. Clearly any terrorist is going to first photograph his target, so vigilance is required.

Except that it's nonsense. The 9/11 terrorists didn't photograph anything. Nor did the London transport bombers, the Madrid subway bombers, or the liquid bombers arrested in 2006. Timothy McVeigh didn't photograph the Oklahoma City Federal Building. The Unabomber didn't photograph anything; neither did shoe-bomber Richard Reid. Photographs aren't being found amongst the papers of Palestinian suicide bombers. The IRA wasn't known for its photography. Even those manufactured terrorist plots that the US government likes to talk about -- the Ft. Dix terrorists, the JFK airport bombers, the Miami 7, the Lackawanna 6 -- no photography.

Given that real terrorists, and even wannabe terrorists, don't seem to photograph anything, why is it such pervasive conventional wisdom that terrorists photograph their targets? Why are our fears so great that we have no choice but to be suspicious of any photographer?

Because it's a movie-plot threat.

A movie-plot threat is a specific threat, vivid in our minds like the plot of a movie. You remember them from the months after the 9/11 attacks: anthrax spread from crop dusters, a contaminated milk supply, terrorist scuba divers armed with almanacs. Our imaginations run wild with detailed and specific threats, from the news, and from actual movies and television shows. These movie plots resonate in our minds and in the minds of others we talk to. And many of us get scared.

Terrorists taking pictures is a quintessential detail in any good movie. Of course it makes sense that terrorists will take pictures of their targets. They have to do reconnaissance, don't they? We need 45 minutes of television action before the actual terrorist attack -- 90 minutes if it's a movie -- and a photography scene is just perfect. It's our movie-plot terrorists that are photographers, even if the real-world ones are not.

The problem with movie-plot security is it only works if we guess the plot correctly. If we spend a zillion dollars defending Wimbledon and terrorists blow up a different sporting event, that's money wasted. If we post guards all over the Underground and terrorists bomb a crowded shopping area, that's also a waste. If we teach everyone to be alert for photographers, and terrorists don't take photographs, we've wasted money and effort, and taught people to fear something they shouldn't.

And even if terrorists did photograph their targets, the math doesn't make sense. Billions of photographs are taken by honest people every year, 50 billion by amateurs alone in the US And the national monuments you imagine terrorists taking photographs of are the same ones tourists like to take pictures of. If you see someone taking one of those photographs, the odds are infinitesimal that he's a terrorist.

Of course, it's far easier to explain the problem than it is to fix it. Because we're a species of storytellers, we find movie-plot threats uniquely compelling. A single vivid scenario will do more to convince people that photographers might be terrorists than all the data I can muster to demonstrate that they're not.

Fear aside, there aren't many legal restrictions on what you can photograph from a public place that's already in public view. If you're harassed, it's almost certainly a law enforcement official, public or private, acting way beyond his authority. There's nothing in any post-9/11 law that restricts your right to photograph.

This is worth fighting. Search "photographer rights" on Google and download one of the several wallet documents that can help you if you get harassed; I found one for the UK, US, and Australia. Don't cede your right to photograph in public. Don't propagate the terrorist photographer story. Remind them that prohibiting photography was something we used to ridicule about the USSR. Eventually sanity will be restored, but it may take a while.

This essay originally appeared in The Guardian.

]]> Thu, 05 Jun 2008 02:44:54 +0000 movie movie-plot security terrorists imagine terrorists terrorists bomb movie-plot terrorists dix terrorists movie-plot threats uniquely wannabe terrorists The War on Photography <![CDATA[Microsoft SDL Process in detail]]> http://securityratty.com/article/24d4e4718f449664310a9dbbe27444a0 http://securityratty.com/article/24d4e4718f449664310a9dbbe27444a0

Hello all – Dave here…

I am currently at RSA and decided to take a few moments to blog about some updates to the Security Development Lifecycle.  Admittedly, I have been “radio silent” on the blog for awhile – for those that know me, that’s usually a warning signal that I am cooking something up…

Anyway, back when we first started this blog we promised that you would see more about the particulars of the SDL – and I think we have done a reasonably good job.  Michael Howard has written some pretty interesting pieces on a wide variety of subjects; bug post-mortems, philosophical notes and the like.  Adam Shostack did a fabulous job on the threat modeling series; Eric Bidstrup took a deeper look at the perceived vs. real benefits of the Common Criteria and I have penned a moderately well received screed or two from time to time.

However, one of the common requests (complaints?) that I have heard is that we have been short on the real “guts” of the SDL – that is to say, a point by point examination of how to apply the SDL. I would argue that Michael and Steve’s book on the SDL is a good primer on how to get started.  I think Jeremy Dallman added more momentum with his “Crawling toward SDL” post, giving some practical advice on how to approach the issue of secure software development from scratch.

Despite these efforts I have heard that people still want more detail – some folks are curious about how an organization the size of Microsoft programmatically drives culture change; others are looking for guidance that can be repurposed for their own organizations and finally, some folks are convinced that we are deliberately holding back some security “secret sauce” for some reason.  Go figure.

With that, let me cut to the chase.  Today, we have made the Microsoft Security Development Lifecycle, version 3.2 available for your perusal on MSDN.  This has been in the works for quite awhile and has involved a ton of folks in SEC and TWC putting in a lot of hours and resources into getting this published (props to Ziv Fass and Jed Pickel!).


As you can probably guess, this is not an exact duplication of the SDL for a number of reasons – but it’s pretty darn close. Given that caveat, allow me to illustrate a few points about this guidance...

 

  • First, we have gone through and removed Microsoft specific jargon, references to internal resources on our intranet, and things that would likely make zero sense to an audience outside of Microsoft (the scrub work was one of the primary inhibitors to publishing previous versions of the guidance).
  • Second, this is a generalized representation of how the SDL is applied at Microsoft for the development of rich client and server applications – while many of the principles apply to the creation of web applications, I would caution you to view this in the correct context.  While Bryan Sullivan has written about web development in the past we’ll have more on SDL and web application development in the future.
  • Third, for all intents and purposes the SDL is considered the “minimum bar” for security and privacy at Microsoft for those products with meaningful security risk; there are a number of teams that choose to invest more time and resources as necessary to meet product team goals that may exceed the SDL.  We salute that behavior.  : )

Finally, in reference to the third point above, I am compelled to say the following. (LEGAL DISCLAIMER ALERT – those with weak constitutions should avert their eyes):

 

The following documentation on the Microsoft Security Development Lifecycle, version 3.2 is for illustrative purposes only. This documentation is not an exhaustive reference on the SDL process as practiced at Microsoft. Additional assurance work may be performed by product teams (but not necessarily documented) at their discretion. As a result, this example should not be considered as the exact process that Microsoft follows to secure all products.

This documentation should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented herein. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, OR STATEMENTS ABOUT APPLICABILITY OR FITNESS OF PURPOSE FOR ANY ORGANIZATION ABOUT THE INFORMATION IN THIS DOCUMENT.

 

For the morbidly curious: Yes, I wrote that; yes, it passes legal muster; no, I am not a lawyer, nor do I play one on TV.  : )

So there you have it – Microsoft SDL 3.2.

There are a few sharp eyed souls that read the blog and will wonder about our publishing schedule for updates – it’s no secret that we examine the SDL every six months and either add new requirements to meet emerging threats or deprecate old guidance.  It has been described by some as analogous to “changing tires on a moving vehicle.”  Let me say now that we will NOT be publishing new SDL guidance on a six month schedule for the foreseeable future – we’ll settle on a reasonable publication frequency and hopefully accelerate over time.


I welcome your thoughts and comments...

 

]]> Wed, 09 Apr 2008 15:13:00 +0000 sdl microsoft sdl sdl process microsoft sdl guidance guidance secure secure software development development Microsoft SDL Process in detail <![CDATA[RFID: Menace in the Far North]]> http://securityratty.com/article/6aa3f563fc4fcc946b80780341b897d5 http://securityratty.com/article/6aa3f563fc4fcc946b80780341b897d5 oF. In the throes of unseasonable spring fever, and with the convenience of snow-free streets, it is not easy to muster sympathy for polar bears laboring under the hardships of global warming. I know, however, that their discomfort on the northern fringes of the continent signifies a larger encroaching problem--one that may someday affect me. What prompts me to spare a thought for those creatures in the distant north is a question about RFID (Radio-Frequency Identification), a broad term for wireless microchips. During a recent discussion about the convenient RFID (tap-and-go) transit cards recently introduced in the Boston area, a colleague of my wife asked why I care about RFID privacy so much. He added, "I don't. I've got nothing to hide."...]]> Thu, 04 Jan 2007 21:00:00 +0000 rfid convenient rfid boston call boston transit cards recently rfid privacy muster sympathy snow-free streets northern fringes RFID: Menace in the Far North