SecurityManagement is primarily concerned with the management of InformationSecurity concerns.
From an Enterprise perspective, the subject includes aspects such as governance, policy setting, process development, fulfill administrative duties, process review (e.g. compliance), risk and opportunity assessment.
These are all performed under the guidance of an agreed IT governance model adopted for the organization concerned, and within the parameters of commonly accepted SecurityConceptsAndPrinciples.
Changing security landscape and trends
Gartner Inc May05 on future of Internet security at http://www.iss.net/resources/pescatore.php
Refocus of security emphasis from perimeter to protecting individual components. See http://www.computerweekly.com/articles/article.asp?liArticleID=136445&liArticleTypeID=1&liCategoryID=6&liChannelID=22&liFlavourID=1&sSearch=&nPage=1
IdentityManagement trend http://www.csoonline.com/analyst/report3172.html
Emerging pattern of DayZero? attacks necessitates proactive measures, so argued an article at http://www.infosecnews.com/features/index.cfm?fuseaction=FeatureDetails&newsUID=d028c6cb-e554-4da3-8a0b-e27092830aee&newsType=Opinion
Future (post 2004) threats see http://informationweek.com/story/showArticle.jhtml?articleID=54201336
OutSourcing SecurityManagement
Not core competency...outsource the work
Yankee Group was reported to be the source security services will be outsourced to managed service providers by the end of the first decade. ".. More of them will see [security] is not a core competency..."
InformationTechnologyGovernance aspects
JohnPescatore of Gartner Inc is promoting SecurityGovernance in Mar05. See http://www.gartner.com/2_events/awards/security_innovation/Business_Must_Measure_and_Share_IT_Security_Innovations.pdf
Why Computers are Insecure
To encourage you go and read the whole thing here are two quotes:
Most products, such as word processors or cellular phones, are useful for what they do. Security products, or security features within products, are useful precisely because of what they don't allow to be done. Most engineering involves making things work. Think of the original definition of a hacker: someone who figured things out and made something cool happen.
Security engineering involves making things not happen.
... [The] try-and-fix methodology just doesn't work for testing security. No amount of functional testing can ever uncover a security flaw, so the testing process won't catch anything. Remember that security has nothing to do with functionality. If you have an encrypted phone, you can test it. You can make and receive calls. You can try, and fail, to eavesdrop. But you have no idea if the phone is secure or not.
IsoSecurity aspects
Careful. BS7799/ISO17799 may be ISO, but the approach to SecurityManagement described below is more generally applicable. Much of the rest of the discussion on this page is not really talking about security management, rather just a set of security topics, which is not the same thing.
Phew, that's a big topic.
I ran our project to get BS7799 compliant. So I know something about this.
Setting it up involved agreeing with senior management what the objectives of information security management were for the company. These summarize as ensuring information is an asset we can rely on, staying compliant with legal, regulatory and contractual requirements, and ensuring business continuity in the event of some disaster.
Next was the preparation of an information security management system; the roles, policies, processes and procedures that were connected with information security. Many of these were new, but it also involved the modification of many other operating processes etc - information security touches on pretty much everything else. Getting all these into use involved a program of education and training.
Alongside this was identifying the information assets we had, together with the other assets that they were dependent on, who the owners were, and together with the owners, performing risk assessments and developing plans for managing the risks to the assets (and managing the assets more generally).
Once we had the system defined and running, we went through an external audit to check we met the requirements of BS7799 - that was important for us as a company, but it shouldn't be the aim of an information security program - that should be ensuring appropriate security for corporate information assets.
Being responsible for information security shouldn't (in my view) be the mandate of the IT security professionals in a company, no more than the responsibility for software quality should be given to a quality department - it's so wide ranging that it has to be made the responsibility of everyone, and in particular, the asset owners.
So ongoing tasks include advising on best practice, continuing education and training, providing assistance to others in following processes, performing risk assessment etc, running the administration of the information management system (audits, management meetings, escalated security incident reviews etc), and reviewing and enhancing the management system so it remains relevant, effective and efficient. In our case, there's quite a lot of preparing for and supporting external audits (we're a managed infrastructure provider, and our clients often want to come and re-assure themselves about our information security).
Later remarks by the same contributor
BS7799 is not the most agile of systems. It's also pretty prescriptive about approach. I happen to think the approach it prescribes is a reasonable one, so if you've got the freedom to choose one for your organization, you might as well choose BS7799's approach. But the way the standard does not allow alternative - and just as valid - approaches was one of the reasons the US objected to Part 2 becoming an international (ISO) standard, so it remains a British (and some other individual countries) standard. (Part 1 is some general text + a list and discussion of controls for consideration. So it's just informative, rather than prescriptive. Part 2 specifies what your Information Security Management System must encompass, and you can get certification of your compliance to that).
You do monitor for those problems and react, of course, since planning up front won't think of everything. But you shouldn't be relying on it as the main mechanism for risk identification and control selection.
It may help to think of this as analogous to the financial controls in a company. You need to design and implement those before running the business - finding out your fraudulent transaction monitoring controls were deficient just after your financial controller leaves for the Bahamas with all your cash is a bit late. You also need to check periodically that the controls are operating correctly, and review them for efficiency and effectiveness. The same is true for information security.
===============================
References
* http://www.thewindow.to/bs7799/
* http://www.bsi-global.com/Corporate/17799.xalter
* http://www.gammassl.co.uk/bs7799/works.html
Reading material on security concerns that BS7799 addresses
* http://www.csoonline.com/read/010104/asp.html
* http://www.infy.com/SETLabs/briefings/pdfs/setlabs_briefings_vol1_no2-integratingforagility.pdf
SecurityManagement in practice
Some of the excellent reading material comes from www.sans.org which specialize in SecurityManagement
Any known application of CapabilitySecurityModel in day to day SecurityManagement matters?
A small anecdote, some users needed to have the ability to unlock specific accounts, NT only gives you three (inadequate) levels (full control, full control over anybody who doesn't have control, and no control). Solution? Emulating caps via delegation from a secure-but-privileged agent, bootstrapping the initial caps from an NT logon. We now grant fine-grained aspects of the user-manager (to say nothing of other applications) without fear that the user will one day figure out that the user-manager lets them do more than just unlock accounts.
See also IsoSecurity IdentityManagement