Speaking of Security – The RSA Blog and Podcast

Incident Management is a broadly used term but in our world of network security, it is inherently defined as the process an organization uses to identify, investigate and remediate a potential or real threat to their network resources and users.

I recently returned from Berlin after attending the EMEA RSA Channel Partner Council with the purpose of discussing RSA’s Security Management and GRC strategies within Europe. For many of the RSA channel partners, this was their first exposure to these concepts. Channel partners have a unique perspective because they are on the front lines selling products and providing implementation services Their success is directly influenced by RSA’s ability to provide the right training, messaging and tools to make them effective.

Welcome to one of Speaking of Security’s newest blogs completely focused on security management, something we’re calling Security Management Insights or SMInsights for short. I am honored to author the initial post in which should be a highly active and thought provoking forum for dialogue related to the challenges facing today’s information security professionals. This is a team blog so you will benefit from hearing from a multitude of product managers from the products and solutions which comprise RSA’s emerging Security Management Suite. We continuously receive the opportunity to interact with customers and analysts and will use this blog to share insights about organizations’ security challenges and strategies.

To my amazement, I still get asked “if I do everything I am asked to do for compliance, am I secure?” To be fair, this question often comes from non-security people.

Earlier this month was one of the highlights of the “Archer calendar year” – the RSA Archer GRC Summit. As always, this event brought our customers together to engage in deep discussions on security, governance, risk management, compliance and a whole host of interesting topics. This is exactly why my blog on this year’s event is about…Harry Potter.

The first principle I think is important to convey is that complexity and scale are inherent in many of the systems we build, and they carry with them risk that grows with size, complexity and scope. In fact, many systems grow to such an extent that they rapidly outstrip the initial design considerations, as is evidenced by obvious examples like Y2K and the need for IPv6.

There has been a great deal of talk about making business processes more transparent. While I think gaining visibility across complex business operations or complicated IT infrastructures is a very important concept, I think there is another concept that is just as important yet is sometimes overlooked. When it comes to truly seeing something for what it is, the dimensions of an object allow us to more clearly define it.

It’s been a year now, or a little more, since To The Heart of the Matter, and this year we’re stepping up the governance, risk and compliance (GRC) stakes in a big way with a new EMC/RSA initiative around enterprise GRC. At the same time, the race to the cloud continues; so it’s time to look at enterprise GRC in the context of Trust and in context of the Cloud anew for 2011. Before we dive into that subject, let’s start with a little more on tools and tasks though by looking at innovation in historical Japan.

On the first day of 2010 my big boss gave to me: a project called G-R-C.
On the second day of 2010 my big boss gave to me: two BCPs and a project called G-R-C.
On the third day of 2010 my big boss gave to me: Three new laws, Two BCPs and a project called G-R-C.
On the fourth day of 2010 my big boss gave to me: Four calling auditors, Three new laws, Two BCPs and a project called G-R-C.
On the fifth day of 2010 my big boss gave to me: FIVE LOSS EVENTS…Four calling auditors, Three new laws, Two BCPs and a project called G-R-C.

RSA GUEST BLOG POST by RSA’s Ian Farquhar: Many years ago, I came across a comment in a support call log which concluded “Fault isolated in Layer 8.” I asked for clarification. “User error,” I was told smugly, by the call log’s author. I also remembered an old acronym from more than a decade before: PICNIC. “Problem In Chair, Not In Computer.”