IBM breaks down the silos – Part 2, the Security silo

One very obvious silo is security and it is a particular issue because the security silo can be so dysfunctional. Application security is the obvious example: the programmers in their silo assume that the security team looks after security once the application is finished (very bad practice, by the way, as “bolt on security” is very expensive, seldom works very well and can lead to usability problems—look at Microsoft’s attempts to make Windows secure). However, the security team in its silo assumes that the application programmers have, or should have, adopted good practice “secure programming” (whatever that is in the detail; it probably doesn’t cover all of application security) and ignore application security. The overall result is that application security is neglected and the business is at risk.

I talked about this issue with Kent Blossom (Vice President IBM Security Solutions) at Tivoli’s PCTU conference—and I was immediately reassured when Kent assured me that his brief ran across both Tivoli (security operations) and Rational (the development of secure application designs)—over all of IBM in fact. There is a lot of security expertise in IBM and I was interested by several initiatives. In particular, approaches to monitoring systems access by privileged users, administrators and the like. When you think about it, external intrusion is quite hard as a way of making money, because once you’re inside you have to know how a range of systems, some perhaps not automated, work before you can, say, move your electronic swag into a real bank account or pot of gold. In contrast, a privileged user who “goes bad” possibly has authorised access to all the systems needed to move money out of the digital domain and can, possibly, order a minion to disregard any rules that are getting in the way.

The trouble is, policing authorised users, especially ones high up in the organisation, can get very career limiting. So, you need high-level policies, operating across any potential silos, which can be agreed by all, and impersonal monitoring and control systems, which implement the policies. Policing high status users in a non-confrontational way is just one of the challenges you’ll face when institutionalising security as part of the business environment: in general, you’ll need to think about provisioning; the possible conflict between keeping resources secure and making them available to the business; continuous validation of security (not just passing a security audit, which is only valid on the day you pass); and integrating business level security with technical security management technology—so business users can be “security aware” without having to become security technologists.

Security is, largely, a people thing and security awareness training across potential silos is probably a better investment than a lot of extra encryption technology for most organisations. Without security awareness, how do you formulate policies telling you what to encrypt? And, encrypted data has to be unencrypted for use so, without security awareness, this probably blows a hole in your security (but data and systems that are so secure you can’t use them are probably counter-productive).

Nevertheless, once you have the people issues in hand, security technology can be a significant enabler, by removing the barriers to implementing security, automating the implementation of security policy as part of the business process and exception-monitoring security exposures. There are now technology solutions for managing and auditing admin accounts, for preventing “toxic combinations” of permissions (such as allowing financial services dealers to settle their own trades) and for the secure management of shared accounts (so that only one person knows the password at any one time and accountability is maintained). And, the future of business security may lie, in part, with applying the techniques of business intelligence to mining security information: intercepting and interpreting events, analysing behaviours and usage patterns, for signs of aberrant behaviour.

I was considerably interested to hear a similar message, that it’s about time that accepted business analysis processes should be applied to managing the work of IT, at IBM Innovate 2010 (the Rational software conference; there’s a video link on the linked page). Once again the synergy between Rational and Tivoli is apparent—I really do believe that silos within IBM are breaking down, not just because IBM tells me so but because I see increasing evidence of silos mixing at the IBM conferences I attend.

In Part 3 of this series, I’ll be reporting more from Innovate 2010, on Systems of Systems and Software Econometrics.