...is not covered to a sufficient extent (for example, perhaps there have been notable failures in the past 12 months) then the creation of a separate IT security department is worthy of consideration.
The purpose of such a department must be identified before its creation, so that everyone is clear as to its reason for being. In Butler Group's opinion, the purpose of the department is to have full responsibility for all information security issues within the organisation, approving all software before its release, and delivering and managing the IT security solutions. It is strongly recommended that the head of the IT security department is a direct report to the chief executive officer, for purposes of integrity. It may be deemed appropriate to give the departmental head the title of chief security officer (CSO), but only if the IT department head is the chief information officer (CIO). If the CSO were to report directly to the CIO (or the IT Security department head to the IT department head), then the security challenges that the company faces could be compromised, with different objectives for each department.
The IT security department does not have to consist of a large number of people – for example, in a mid-sized, US-based healthcare organisation the IT security department has seven people. However, the individuals in this department take on multiple roles. In addition to the department head, there is a need for a contingency planner – this person must not only be involved in IT contingency planning, but business contingency planning as well.
Various IT administrators are also required, as are solution testers. The testing capability is required to test all solutions that are developed by the IT department, and the IT security department should also be responsible for approving (from a security perspective) the purchase of Commercial Off-The-Shelf (COTS) solutions that the IT department recommends.
Therefore, the IT security department does not have to be a big department, but it is essential that it carries responsibility for these functions, in order to be successful and accountable. Having a separate IT security department can have a number of benefits. One of the main benefits is the reduced IT security risk for the organisation, and a consequential benefit of that is improved IT security effectiveness. These benefits are achieved through the ability of the IT security department to concentrate on a single aspect of IT solutions – that of security. By reviewing the security of any system, whether built in-house, COTS or customised, the department can devote the time and expertise necessary to ensuring that the organisation's security is not going to be compromised. With the best will in the world, having the IT department undertake such a task is not always easy – as those of us with any amount of IT experience are aware, the testing aspect of any solution is compressed if time is of the essence.
By giving the IT Security department the responsibility and accountability for the security aspect of a solution, it is possible to ensure that the security aspects are fully tested before being put into a live environment. Further benefits that can come out of an IT Security department include the operational security, information assurance, and business security that arise from having a separate functional unit. One only has to look at security breaches that have happened to realise the importance of operational security, with the ultimate protection of brand image. The on-line banking organisation Cahoot, for example, suffered a breach just over a year ago, when it became clear that changes were made to Cahoot’s online systems some 12 days before a flaw was discovered, and it was confirmed that the subsequent security breaches were caused by the upgrade. Had a separate IT security testing function been in place at Cahoot, I believe it would be less likely that such a breach would have happened – because the flaw would have been found before the upgrade was implemented.
It is of course not all a bed of roses when separating out the responsibility for IT security into another department, and there are other issues that need to be addressed. These include the fact that the management and C-level directors of the organisation must be fully aware of information security risks; only in this way can they be committed to the aims and objectives of the IT security department. Following on from this, setting up the department is not the only executive responsibility; ensuring it runs satisfactorily, achieving objectives, is also required. To this end, executive sponsorship and reporting is vital, for the department to have "clout" around the organisation. This could, however, make the department appear to be "the heavy mob", and this also needs to be avoided.
There is no easy answer to this; it will be a fine balancing act and needs to be handled carefully. The alignment of IT security department objectives with organisational objectives may seem an obvious point, as it applies to all departments within the organisation, but it is important that this point is made. Furthermore, it may help with the issue raised above, regarding the department's appearance as "the heavy mob". A general understanding that the IT security department is subject to the same aims and objectives as the rest of the company will help the department, and indeed the whole organisation, to fully understand its role.
The final point is that the roles and responsibilities within the department are unlikely to remain static. Periodic reviews of roles and responsibilities are required, perhaps every six months or so, with updates to those roles and responsibilities being communicated to the department and the rest of the company as and when required. This will help address the changing face of the security issues that organisations must adapt to, and perhaps some companies will be keen to undertake reviews on a more frequent basis.
The creation of an IT security department is not necessarily the right way forward for every company, and there could be very good reasons for retaining such a function within the IT department. The benefits, however, can be significant, especially when cases have arisen where IT security needs to become more ingrained into the business. The suggestion is that the separation of the two could be considered, and in certain circumstances prove invaluable.







Talkback
Liability and purchases are two things underestimated.
With increased and realistic liability enforced those that call the shots either won't make the same mistake twice or won't be around to do the same thing wrong three times in a row.
Another thing is to give more purchasing (decision) powers to those that actually have to maintain, secure, budget for, etc whatever someone else in the organization wants. More often then not lots of organizations are faced with hotshots that "introduce" something "significant" (totally clueless of overall details that matter) by means of: here's something new, purchased and delivered already, that promises to fullfill all my dreams of today, now make that a reality even if that's impossible with the resources and time not provided for.
As for seperating IT security from more normal IT department activities. Given the usual interaction level and mutual understanding between, say, LAN/WAN, Server, Desktop, ServiceDesk, Management, Mainframe, Development, etc guys introducing yet another specialized department is likely to mess up things and create additional kingdoms and internal conflicts even more.
In short, organizations are well advised to ensure that everyone in their IT staff has multi discipline understanding about things that matter. That won't happen overnight but the fact is that most organizations are better off with a bunch of guys that have working experience and understanding concerning plenty of specialities working within one big happy IT family then when compared with seperated, highly specialized, IT departments cooperating together.
Even shorter, if security is that important then security should be part of the first initial thoughts of something new up to and including the entire life cycle of everything (who says that security stops and starts within IT anyway?).
Good security starts at the very beginning. Even before the initial designs. Introducing good security afterwards is only a sales man dream because it can't be done. You'll end up paying twice for half as much while needing more each and every time, time and time again. The only real way to get rid of less then good security is to rebuild from scratch. In a practical way ofcourse.
Security is either a company wide effort, top to bottom, or it's a paper tiger. And a costly one at that because more often then not the way companies handle their internal security is a good indication how they handle almost everything else.
It is interesting that you approach security in the same manner as providing an IT service. Yes, both are evolving and moving towards being considered as peers in the boardroom .
But it is also important to consider that the mandates and goals for security and IT differ. Trying to roll security in the IT umbrella could be compromise the ability of the security organization being able to operate as an independent set of eyes for the business. IMHO, that is a very valuable aspect of this seperation and security should be regarded as a value added, not just a compliance measurement function.
Yes, security is going to be distributed/ntegrated across the IT operations groups and that is going to be challenging to implement but it is also important to maintain the individuality of the security organization.
An independent set of eyes for the business should be achieved by auditors. A quality assurance team if you will that acts as roaming coaches, top to bottom, across the various business processes taking into account every aspect that makes, breaks, improves, demotes such processes. Security is just a part of that all. An important one at that but still a part.
Once you take out and highlight security alone it'll become a product. A goal in itself. Since good security is an integral part of just about anything it's exactly for that reason that one shouldn't seperate (highlight) it.
The focus should be that without build-in security from scratch one simply doesn't have what it takes. One is simply working with incomplete processes. Time for some serious re-evalutions in such events.
Security is not an add-on module. Although plenty of sellers out there that will make you think otherwise if you're not carefull.
IT security is a very broad term to debate upon! The very term triggers a shiver! Security can be at different levels: viz., perimeter, physical and aplication level.
Each of the above should be looked in as a seperate area of security study!
The question is: Who wants to take the responsibility for a possible break-down? Break down could be in terms LAN, WAN, networks, IP level or could be on the application level in terms of Phishing attacks, Dos or DDoS and many more Internet based attacks.
IT Security is a broad term to be used for a possible decision to be made. It would be intresting to debate on the same and a possible speculation cannot be ruled out!
The way I see it as a IT security analyst, in terms of aplication level security, seperating IT from IT Security has its own Pros and Cons.
Pros could be an efficient team out there to deal with and come out with possible solutions in terms of the right cryptographic and Encryption being used and a lot more on those grounds for the same in co-ordination with the Peers of the company. Cons because of the word co-ordination I used earlier.
There are more than one areas of IT that needs to works in coordination with IT Security. There still would be a part of work that the IT and the IT Security guys would need to do together under one roof, across the table.
Likewise, there could be a seperate entity concentrating on specific areas of security viz., application.
Once you break down security into manageable items you'll find later on that the sum isn't better then it's parts. Best thing to do is to go for the sum at once and tap individual departments on the fingers for not doing their part in the overall sum that makes up overall security.
In short: every part should be worried about the sum of security. Not just their part of the equation. Unless you think that having a piss contest will actually lead to lasting results security wise overall. It won't. Remember: overall security is about finding and avoiding weak spots. Whereever they are.