As regards interception of data packets in the public medium i.e. Internet (whether at a cyber cafe or at the national/regional Internet gateway), I believe Indian Telegraph act 1885 still rules as there is no substitute to that yet. All other constitutional, statutory and regulatory references are inferential. So the only agencies who have any say are the Govt appointed and approved ones as per due process and even if it steps on citizens privacy. The new privacy regulation is likely to trample a little more on citizens' privacy than make the interference lesser. Similar Laws exist in most countries.
Monitoring with in organisations is not seen with the same light. Here privacy laws if any apply squarely; hence a variety of interpretations abound. While India, US and China permit unlimited monitoring of internal electronic communication after generic notification/intimation to employees, Australia, Japan, Canada and a few others permit the same after specific intimation. Europe on the other hand has a lot of variety; some countries require specific intimation to employees and individual acceptance by them, some exempt 'private'/'personal' marked mails/content within office mail communication and many such subtle variations.
Privacy Laws mandate such specific intimation to employees and the variations are almost as many as there are countries in Western Europe; the Russians and several East European countries have a much easier take on privacy. There are technological fixes that could identify whether employees are misusing the given facilities without necessarily singling out the perpetrator. However, there may not be possibility to serve individual notices without identifying offenders. Doing so would be a serious offence, in say Germany. Actually, in Germany, even general monitoring would be an offence without following laborious protocols to initiate the same.
But all in all, the very privacy regulations themselves are being re-looked or at least re-interpreted as is the failing welfare state concept prevalent in Western Europe for more than half a century. Enterprises which used to earlier leave alone data interceptions altogether are employing full time privacy officers and legal advisers not only to ensure compliance to the privacy regulations but see to it that the internal monitoring program is managed with in limits of the law. We are sure to hear more of this from Europe topic in coming times.
Back to the Govt monitoring, Govt agencies in poorly oversighted systems tend to go overboard with the use of power when consequences are not known to be severe. Same is the case with lawful monitoring. Excesses are rampant and law enforcement has pretty much a free hand, be it for tapping phones (land line/mobile) or track Internet communication..
Tuesday, December 21, 2010
Wednesday, December 8, 2010
On ROSI (Return on Security Investment)
One way to look at it is to calculate the actual cost of the people, platforms and services engaged full time or specifically security related projects; and compare it against Legal, Financial, Operational and Reputations costs. But that is a myopic exercise done from a perspective of weakness and insecurity. And there is never going to be a sure fire way of accurately computing legal and reputations costs.
A quasi-quantitative way is to take the following approach:
1. Identify in consultation with Management/business what all need protection/security and document items under groups - services, operations, systems, facilities, people and any other.
2. For each of the above items, document the business function/user who concurs that the protection/security is necessary
3. Assess the security risks to the above items and arrive at the ideal/best/cost effective means to provide protection/security
4. Discern what protection/security out of the above means has already been deployed as part of the initial architecture/design
5. Prepare a phased road map for deploying rest of the means and quantify their cost
6. Take a sign off from the user function(s) on whether they would like to bear the above documented costs or accept the documented security risks
7. If they would rather bear the cost, the benefit they derive out of the said security deployment can be then taken as the return on the security investment cost calculated above (point 5)
Another approach when CISO has strong management buy-in:
1. The very fact that a CISO has been hired is to meet an existing business need to provide security/protection
2. What we do with what we have - Just having security systems and processes does not ensure security. They have to be designed, configured, operated and reviewed efficiently and intelligently as per the organisations operating environment and business needs. Common examples are gaps in Access Control systems, Vulnerability Assessment platforms, SIEMs, Patching and AV infra etc
3. How we do, what we do - The approach should be business oriented, as business wants it and because it will facilitate/enable business not because the CISO wants it or because it's a security best practice. CISO's advisory and Security best practices are important but they have to be aligned to the business requirement and not vice-versa.
A quasi-quantitative way is to take the following approach:
1. Identify in consultation with Management/business what all need protection/security and document items under groups - services, operations, systems, facilities, people and any other.
2. For each of the above items, document the business function/user who concurs that the protection/security is necessary
3. Assess the security risks to the above items and arrive at the ideal/best/cost effective means to provide protection/security
4. Discern what protection/security out of the above means has already been deployed as part of the initial architecture/design
5. Prepare a phased road map for deploying rest of the means and quantify their cost
6. Take a sign off from the user function(s) on whether they would like to bear the above documented costs or accept the documented security risks
7. If they would rather bear the cost, the benefit they derive out of the said security deployment can be then taken as the return on the security investment cost calculated above (point 5)
Another approach when CISO has strong management buy-in:
1. The very fact that a CISO has been hired is to meet an existing business need to provide security/protection
2. What we do with what we have - Just having security systems and processes does not ensure security. They have to be designed, configured, operated and reviewed efficiently and intelligently as per the organisations operating environment and business needs. Common examples are gaps in Access Control systems, Vulnerability Assessment platforms, SIEMs, Patching and AV infra etc
3. How we do, what we do - The approach should be business oriented, as business wants it and because it will facilitate/enable business not because the CISO wants it or because it's a security best practice. CISO's advisory and Security best practices are important but they have to be aligned to the business requirement and not vice-versa.
The inevitable CISO and the future ubiquitous CSO (under a pseudonym)
The CISO has come to be in the last one decade a position which can not be wished away. However, but for mature business houses, it finds itself being tossed about quite a lot - sometimes under the CIO, and other times under heads of Operations, Finance, HR, or some other corporate function. Rarely does it have access to the board and even less the board room. It's as if most people think he is required but most can not decide where he belongs.
This is connected to the evolution of the CISO function from IT Security to Information Security. While definitely it has come out or at least on the way of coming out of the IT function, the CISO has quite not been able to establish the domain spread it requires to fulfill the Information Security responsibility for an enterprise. From being a transactional security organ which ensures security of IT transactions, CISO has gathered steam to encompass the operational risk management, the security governance and audit framework as also the disaster recovery apparatus.
However, there are several other complementary and competing security and related domains which exist in penny pockets in other parts of the organisation which dilute the CISO and often are beyond his control, some times at cross purpose. These are Physical Security, Enterprise Risk, Business Continuity, Privacy, Fraud, Investigation and their ilk who masquerade with other names.
Organisations would eventually see the business benefit of integrating all these complementary functions and consolidate them under one head under some enterprise function or create a new function for it; if only to stop them from their never ending turf war and one-up-man ship . But it is unlikely to bear a designation with a S in it standing for Security. It's simply not sexy enough, especially when there are so many more hep sounding names in the stable. So CSO may never happen, as it also has not happened till date.
Physical security has become interesting and technical. There is increased room for convergence between PS and IS. But rarely, if ever, there has been an organisation where the two are under one head. And whenever they are or when they would be together under umbrella, it will not bear the name of CSO but something rather fancy and unrecognisable.
This is not necessarily a bad thing. It will bring security and all the complementary functions into the middle of business relevance, hopefully with the head of this heterogeneous entiry being from a business background but with a strong understanding of information security, and having a place in the boardroom - if not the board.
This is connected to the evolution of the CISO function from IT Security to Information Security. While definitely it has come out or at least on the way of coming out of the IT function, the CISO has quite not been able to establish the domain spread it requires to fulfill the Information Security responsibility for an enterprise. From being a transactional security organ which ensures security of IT transactions, CISO has gathered steam to encompass the operational risk management, the security governance and audit framework as also the disaster recovery apparatus.
However, there are several other complementary and competing security and related domains which exist in penny pockets in other parts of the organisation which dilute the CISO and often are beyond his control, some times at cross purpose. These are Physical Security, Enterprise Risk, Business Continuity, Privacy, Fraud, Investigation and their ilk who masquerade with other names.
Organisations would eventually see the business benefit of integrating all these complementary functions and consolidate them under one head under some enterprise function or create a new function for it; if only to stop them from their never ending turf war and one-up-man ship . But it is unlikely to bear a designation with a S in it standing for Security. It's simply not sexy enough, especially when there are so many more hep sounding names in the stable. So CSO may never happen, as it also has not happened till date.
Physical security has become interesting and technical. There is increased room for convergence between PS and IS. But rarely, if ever, there has been an organisation where the two are under one head. And whenever they are or when they would be together under umbrella, it will not bear the name of CSO but something rather fancy and unrecognisable.
This is not necessarily a bad thing. It will bring security and all the complementary functions into the middle of business relevance, hopefully with the head of this heterogeneous entiry being from a business background but with a strong understanding of information security, and having a place in the boardroom - if not the board.
Saturday, October 16, 2010
DRDO's brand new OS
Everyone worth his name, Govt or enterprise, has tried to make it's own OS from time to time; and other Indian agencies have tried this before as well. And now it's DRDO's turn.
I wandered over the net and found some serious criticiam and some slander. One such place was http://www.schneier.com/blog/archives/2010/10/indian_os.html. I wondered why many 'western' posts had a sharp tounge against Indian as such ....
Sure India has it's share of flaws; some major ones but India has managed to keep a democracy alive and kicking; and in today's world that's almost a miracle. Despite it's flaws (so well pointed out in the posts), India has the largest pool of fairly good English speaking and fairly good quality programmers, developers, testers and integrators.
Just 10 years back, Indians themselves considered computerisation of Indian railways and Indian banks impossible. They have broken their own boundaries....
Indian press is ferocious and free, that's why our scandals tumble out regularly.
Agreed, it's a fact that DRDO has not too much to show compared to NASA but for a country where real technology happened just about 15 years back; it's progress in missile, nuclear, IT and bio-technology etc are not worth giving a pass. And all this despite the corruption, poverty .... snakes, elephants, and whatever else people who are unaware of the new India can imagine.
And Indian GDP has been growing more than 8% for last more than a decade. And the recession that's gripping the west still very strongly did barely touch India. Indian IT giants with 100,000 work force plus managed to shed just about 1% of employees.
I think many in the west need to change their attitude towards the world outside their back yards; especially the new world of the last decade plus. India is fast moving and fast changing. Many Indian expats themselves have already changed their attitude of hopelessness about their country of birth and some have returned to equal to or higher paying jobs at Bangalore, Gurgaon or Hyderabad ...
The new generation of Indian youth is getting involved with Govt projects. Indian Govt is one of the major investors on infrastructure, technology, power, compared to it's industry counterparts.
There are young people there who are making it their life's mission to work in backward parts of India, connecting it's people to it's resources, and facilities. Such people are the backbones and bulding blocks of the emerging India.
It's a people whose time has arrived; may be a OS is not rocket science after all.....
I wandered over the net and found some serious criticiam and some slander. One such place was http://www.schneier.com/blog/archives/2010/10/indian_os.html. I wondered why many 'western' posts had a sharp tounge against Indian as such ....
Sure India has it's share of flaws; some major ones but India has managed to keep a democracy alive and kicking; and in today's world that's almost a miracle. Despite it's flaws (so well pointed out in the posts), India has the largest pool of fairly good English speaking and fairly good quality programmers, developers, testers and integrators.
Just 10 years back, Indians themselves considered computerisation of Indian railways and Indian banks impossible. They have broken their own boundaries....
Indian press is ferocious and free, that's why our scandals tumble out regularly.
Agreed, it's a fact that DRDO has not too much to show compared to NASA but for a country where real technology happened just about 15 years back; it's progress in missile, nuclear, IT and bio-technology etc are not worth giving a pass. And all this despite the corruption, poverty .... snakes, elephants, and whatever else people who are unaware of the new India can imagine.
And Indian GDP has been growing more than 8% for last more than a decade. And the recession that's gripping the west still very strongly did barely touch India. Indian IT giants with 100,000 work force plus managed to shed just about 1% of employees.
I think many in the west need to change their attitude towards the world outside their back yards; especially the new world of the last decade plus. India is fast moving and fast changing. Many Indian expats themselves have already changed their attitude of hopelessness about their country of birth and some have returned to equal to or higher paying jobs at Bangalore, Gurgaon or Hyderabad ...
The new generation of Indian youth is getting involved with Govt projects. Indian Govt is one of the major investors on infrastructure, technology, power, compared to it's industry counterparts.
There are young people there who are making it their life's mission to work in backward parts of India, connecting it's people to it's resources, and facilities. Such people are the backbones and bulding blocks of the emerging India.
It's a people whose time has arrived; may be a OS is not rocket science after all.....
Thursday, September 9, 2010
New Perspectives on Asset Based Risk Assessment
Asset based risk analysis approach does not in any way negate the specific risk assessment methodology that a specific organisation chooses/decides for itself. While the list of assets may run into millions of rows, they can mostly be grouped into asset types for the purpose of risk asessment and comprehensive risk for each asset type can be identified as per a risk assessment methodology which should be specific to an organisation.
Enterprises have often adopted different groupings of assets; the ones that I have seen practically working are service based and business process based. Basically, one documents the services offfered by the organisation (typically in case of an organisation selling goods/service to other organisations/businesses) or the business processes running in the organisation (mostly in organisations selling products/services to end customers). Then; per service/business process, identify the asset groups used and risks to them from a customised T-V list (repository of threats & vulnerabilities specific to the concerned sector & the individual organisation); with a bit of quantitative or qualitative scoring (as appropriate) workout the risk grade (High/medium/low) and you have your risk list which can be converted to a risk map for relevant target audience.
Risk based selection of controls similarly does not preclude common sense, best practices, incident learnings, client specifications etc. The customised T-V list above should capture all these elements and more. When a risk assessment exercise is done, it is not merely how CIA impact an asset directly but how the said asset is used in a service or process and how extensive/unique/customised the T-V is that brings out the risks to the specific business entity.
It is for the enterprise risk manager to come up with this methodology and all risk relevant functions (information security, physical security, OH&S etc etc) to conduct their risk assessments adhering to this laid down methodology.So the asset base should be taken as a base only; with a layer of organisation specifc criterion above it to add that special customisation for a specific organisation. Thus, even within the same Industry, two organisations can have a very different risk assessment methodology with such an approach.
Enterprises have often adopted different groupings of assets; the ones that I have seen practically working are service based and business process based. Basically, one documents the services offfered by the organisation (typically in case of an organisation selling goods/service to other organisations/businesses) or the business processes running in the organisation (mostly in organisations selling products/services to end customers). Then; per service/business process, identify the asset groups used and risks to them from a customised T-V list (repository of threats & vulnerabilities specific to the concerned sector & the individual organisation); with a bit of quantitative or qualitative scoring (as appropriate) workout the risk grade (High/medium/low) and you have your risk list which can be converted to a risk map for relevant target audience.
Risk based selection of controls similarly does not preclude common sense, best practices, incident learnings, client specifications etc. The customised T-V list above should capture all these elements and more. When a risk assessment exercise is done, it is not merely how CIA impact an asset directly but how the said asset is used in a service or process and how extensive/unique/customised the T-V is that brings out the risks to the specific business entity.
It is for the enterprise risk manager to come up with this methodology and all risk relevant functions (information security, physical security, OH&S etc etc) to conduct their risk assessments adhering to this laid down methodology.So the asset base should be taken as a base only; with a layer of organisation specifc criterion above it to add that special customisation for a specific organisation. Thus, even within the same Industry, two organisations can have a very different risk assessment methodology with such an approach.
Tuesday, July 6, 2010
Data Loss Prevention : The search for a Silver Bullet
Whereas, deployment of a comprehensive DLP solution should be a risk mitigation measure which emerges from a systematic Risk Assessment based on business and security objectives; the reality is that it is resorted to mostly as a remedial measure in the aftermath of a particularly nasty incident. Sometimes, a DLP comes about when business does well and security gets an opportunity to push through a big security investment. One does not see too many instances of DLP implementation from pure selling either; despite aggressive selling from DLP solution providers. The practical experience is consistent across industry sectors; and the essence is that while Data Loss concerns are mostly real, remedial measures are mostly reactive and almost always ineffective.
Management wakes up to Data Loss threats almost always after significant data which is important to management has been lost or a major incident has resulted from an instance of data loss. While the lost data itself may not have been very important in the perception of management, the incident may have caused grave concerns which is unacceptable to management from strategic perspective. On the other hand, Information Security function/department is typically engaged with more immediate concerns; and when it gets alive to the threat of data loss, it gets entangled with a silver bullet DLP solution. However, DLPs cost big; and in the absence of a sensitised and informed environment, the idea of a full blown DLP solution does not find much favour. So security has to wait for a bad incident or good revenue year!
Management wants DLP to do mail filtering with a view to analyse content and prevent undesirable mail from going out. For some reasons, management believes that mail is the most potent and viable medium through which data can be leaked. Many operational departments including IT, sometimes even Information Security, concur with this thought. As a result, the DLP that gets deployed with such mindset ends up doing email/content filtering. It's a different thing that even the full blown DLP solution eventually ends up with similar restricted usage, more of this later.
When a DLP is eventually deployed, we expect a miracle solution and we could not be further from the truth. It has a steep learning curve, a long gestation period including setting up policies with contextual content which does not come from business very easily. Once we have it deployed, it detects more nuisance than data loss; tweaking them to reduce false positives takes forever. Unintentional data loss gets detected while planned data theft can be one step ahead of the policies set up in the DLP to detect the same.
A deeper analysis of data loss leads to the understanding that there could be several data leakage avenues, beyond emails. Mass storage devices are a big concern. They are either not disabled, or if disabled (through group policy or end point solutions), a lot of exceptions are provided with no expiry and with tracking through exception management. Also, there are a lot of holy cows with admin privileges who then are free to work around such disabling. As one can easily guess, the big boys comprising of senior management, IT administrators, marketing & sales stars etc, are all exempted. Admin rights provisioning itself is another big culprit. It not only lets the person enable use of mass storage, if disabled; it also permits a whole lot of policy reversals, silencing end point, initiating P2P traffic, enabling execution of exe files, downloading software etc. And of course there is no tracking of these exceptions as these are not treated as exceptions in the first place. All IT guys, security folks, and everyone in management who is anyone worth mentioning has admin rights in a typical dysfunctional (security-wise) organisation. Indiscriminate dissemination of information to all and sundry is also a common causal factor for potential data loss. The golden principle of need to know is rarely followed; resulting in a lot of information being possessed by a lot of people much beyond their business requirement and role privilege. Uncontrolled internet access is again a big hole contributing to very efficient means of massive data loss. With no logging, no control on uploading files and no monitoring of access; it is often the most used and least known about.
None of the above threats require a while elephant DLP to be treated. Many of them require a strong management intent and effective security drive to be implemented with telling effect. For example, revoking admin rights and disabling USB mass storage go a long way to prevent data loss from an office environment. Controlling and logging internet access and disallowing data upload is not as challenging activities as deploying a DLP but provide much more effective data loss prevention capabilities. And need to know is a culture issue which can be enabled though sound technology measures such as making efficient & easily accessible shared space available and popularising them through crafty programs.
Data loss is a critical issue for today's information/data driven business; it is vindicated by the increasing number for data loss related incidents and the increasing cost of those incidents to corporations. Implementing a compressive and effective DLP program may be a long term solution but there is a lot that can be done before that and a lot needs to be done with the DLP itself to make it useful.
Deepak Rout, CISO, Uninor
Management wakes up to Data Loss threats almost always after significant data which is important to management has been lost or a major incident has resulted from an instance of data loss. While the lost data itself may not have been very important in the perception of management, the incident may have caused grave concerns which is unacceptable to management from strategic perspective. On the other hand, Information Security function/department is typically engaged with more immediate concerns; and when it gets alive to the threat of data loss, it gets entangled with a silver bullet DLP solution. However, DLPs cost big; and in the absence of a sensitised and informed environment, the idea of a full blown DLP solution does not find much favour. So security has to wait for a bad incident or good revenue year!
Management wants DLP to do mail filtering with a view to analyse content and prevent undesirable mail from going out. For some reasons, management believes that mail is the most potent and viable medium through which data can be leaked. Many operational departments including IT, sometimes even Information Security, concur with this thought. As a result, the DLP that gets deployed with such mindset ends up doing email/content filtering. It's a different thing that even the full blown DLP solution eventually ends up with similar restricted usage, more of this later.
When a DLP is eventually deployed, we expect a miracle solution and we could not be further from the truth. It has a steep learning curve, a long gestation period including setting up policies with contextual content which does not come from business very easily. Once we have it deployed, it detects more nuisance than data loss; tweaking them to reduce false positives takes forever. Unintentional data loss gets detected while planned data theft can be one step ahead of the policies set up in the DLP to detect the same.
A deeper analysis of data loss leads to the understanding that there could be several data leakage avenues, beyond emails. Mass storage devices are a big concern. They are either not disabled, or if disabled (through group policy or end point solutions), a lot of exceptions are provided with no expiry and with tracking through exception management. Also, there are a lot of holy cows with admin privileges who then are free to work around such disabling. As one can easily guess, the big boys comprising of senior management, IT administrators, marketing & sales stars etc, are all exempted. Admin rights provisioning itself is another big culprit. It not only lets the person enable use of mass storage, if disabled; it also permits a whole lot of policy reversals, silencing end point, initiating P2P traffic, enabling execution of exe files, downloading software etc. And of course there is no tracking of these exceptions as these are not treated as exceptions in the first place. All IT guys, security folks, and everyone in management who is anyone worth mentioning has admin rights in a typical dysfunctional (security-wise) organisation. Indiscriminate dissemination of information to all and sundry is also a common causal factor for potential data loss. The golden principle of need to know is rarely followed; resulting in a lot of information being possessed by a lot of people much beyond their business requirement and role privilege. Uncontrolled internet access is again a big hole contributing to very efficient means of massive data loss. With no logging, no control on uploading files and no monitoring of access; it is often the most used and least known about.
None of the above threats require a while elephant DLP to be treated. Many of them require a strong management intent and effective security drive to be implemented with telling effect. For example, revoking admin rights and disabling USB mass storage go a long way to prevent data loss from an office environment. Controlling and logging internet access and disallowing data upload is not as challenging activities as deploying a DLP but provide much more effective data loss prevention capabilities. And need to know is a culture issue which can be enabled though sound technology measures such as making efficient & easily accessible shared space available and popularising them through crafty programs.
Data loss is a critical issue for today's information/data driven business; it is vindicated by the increasing number for data loss related incidents and the increasing cost of those incidents to corporations. Implementing a compressive and effective DLP program may be a long term solution but there is a lot that can be done before that and a lot needs to be done with the DLP itself to make it useful.
Deepak Rout, CISO, Uninor
Saturday, May 8, 2010
Security Metrics : Relevance, Utility & Implementation
Preparing a Security Metrics Framework
Security Metrics is a key tool in the business of Information Security. But it has often been debated that objective measurement of security related parameters is by and large difficult and when possible, rather inaccurate. However, with security having emerged as a design criterion in most organizations, systems and software, and financial consequences of security violations having become extremely high, there is growing acceptance amongst most CISOs and even the CIO/CTOs about the need for security metrics. It is also a prevalent view that these metrics should be aligned to business KRAs.
But the agreement almost ends there and there are differences of opinion regarding many aspects. In most organizations, an independent Information Security stream evolves in due course of time and is often carved out of the IT department. Thus, besides having business KRAs-aligned security metrics, presence of apex level directives is essential as a key facilitator for the security metrics program.
With that in place, the next step would be to prepare an exhaustive body of metrics which cover all areas of the operational landscape. To arrive at the set of metrics that best fit your organization, we need to answer a few very relevant questions:
a. Which metrics are relevant for the organization? Answer to this question will lead to weeding out those metrics which add bulk to the metrics program but no value. In security metrics, more is not necessarily better. Also, there may be a tendency to propose metrics based on the ease of availability, the so called criterion of STTCBM (“Security Things That Can Be Measured”). However, ideally we should like to see a small collection of quantitative values that are a good characterization of the current security state of an organization as well as a measure of its dynamic rate of change (hopefully improvement) over time. For executive audiences this is critical. The best candidates for such metrics should first focus on outcomes as opposed to the policies, people, processes, and technologies that have been put in place to achieve those outcomes. For example: Number of Security Incidents of varying severity for a given period in the entire organization, Mean Time between Security Incidents and Mean Time for closure of a Security Incident.
b. Are these measurable? In the scope of Security Metrics, we have several tangible or objective things such as number of virus incidents or number of people trained etc. And we also have certain intangible things such as level of security awareness, effectiveness of Risk Assessment etc. It is relatively easy to measure tangible aspects. But measuring intangible things poses several challenges and it is easy to give into the temptation of sticking to only those which can be measured. Given the intangible but vital nature of security awareness, it is definitely worth putting effort into the measurement of such subjective factors, rather than relying entirely on easy-to-measure but largely irrelevant objective factors. Measuring anything makes it easier to drive improvements but measuring the wrong things leads to improving the wrong things.
c. What Business goals do they serve? The hard part is not measurement per se but is figuring out what parameters to measure and what needs to be done to make them measurable. Information security is a complex field with ramifications throughout the organization. It is unrealistic to expect to find a few simple measures. It is important to think long and hard about what actually needs to be improved before building a measurement system, or at least before casting it in stone. First of all one should be absolutely clear about the purpose of the measurements, how it will be reported and what use do they serve. We should know who will ‘consume’ them, and what we expect the consumers to do with them. If you have a clear purpose in mind (e.g. to inform management about the information security program, to justify the investment and/or to improve the program’s effectiveness), it will help determine which metrics you need.
Overcoming Challenges
After the above questions have been answered, we then have to initiate the process of data collection from the relevant systems or processes, analyse this data and process it to formulate the metrics. Some challenges may be found at this stage. There may be challenge of getting stakeholders buy in for collecting metrics data from the source(s). And once that is surmounted an even bigger challenges could be automating these metrics.
The concerned departments whose operations come under the scanner may have issues in making the data for metrics available while the Information Security department remains thirsting for information. Nothing paves the way smoother for a Security Metrics program than having direct support from top management. Every security conscious organization should have an apex body or a council where security matters are tabled in a regular periodicity. This forum then serves as the driving force behind not only the Information Security governance and policy implementation processes but also that of the Security Metrics program. The security metrics should be handled by a metrics program manager under the CISO and the process should be periodically audited independently.
Metrics are very good if you can obtain them in an automated way. It is of importance because errors inherent in human intervention can be avoided; also the program becomes sustainable as well as scalable. Another critical aspect is independence. When automated the data would come independently from the source of collection rather than provided by the owner of the source. Essentially this would avoid a conflict of interest. However, automating metrics collection/reporting has its own pitfalls, the main one being a bias towards metrics that can be collected and analyzed in an automated fashion, which implies using data extracted from the IT systems. Unfortunately, some of the most interesting aspects of Information Security are the people and not the systems. For example, the effectiveness of policies and awareness activities can be measured by observing employee's changing behaviors. And unfortunately very few of those changes can be easily measured.
Objective and Relevance
There are many advantages associated with security metrics such as facilitating risk quantification leading to management decisions, optimum resource allocation etc. However, one of the main goals is that metrics should lead to positive change in behavior. While they should focus on generating and presenting data which point to the deficiencies that need to be plugged, it must be remembered that the very behaviors that these metrics want to amend have come into existence not purely out of users uninformed habits. Often, it is because of the way IT is rolled out in a company. And almost always, it is a cultural issue; culture of the organization as also of its people. It is clearly apparent that security is not a technology problem; we may have the most complex mathematics and cryptography; but all the security in the world may not help. Security is a social issue; it is a trust issue. The gaming industry and marketing industry are very adept at manipulating peoples’ behaviors. We may actually need to involve Security Psychologists and may be some marketing people to prepare a security marketing campaign to motivate people to do the right thing. And the right thing is of course; that which has been measured to be the most desirable and effective behavior for the security issue at hand.
Information security, like risk, is a notoriously difficult area to measure, the main problem being how to measure the ‘lack of incidents’. Some concerns in doing this are enumerated below:
• If the information security risk analysis is accurate, and if effective information security controls are implemented, security incidents should be avoided, or at least their number and severity should reduce. (That’s primarily what we’re trying to achieve through information security, though it is not all. There are other important benefits too: strong information security controls improve management’s confidence, making it easier to enter into new business ventures that would otherwise be too risky to consider. For some like financial services, security is absolutely valuable for their core business and therefore a fundamental brand value.)
• If we simply measure the number and severity of incidents, we will have some numbers to play with but what will those numbers actually tell us?
o If the numbers are lower than before we started the information security program, we could claim success but what if the number and severity of incidents had fallen anyway? For example, we see fewer website defacements now than a decade ago: is that because websites are better protected now (control improvement) or because there are fewer hackers actively targeting website defacements (threat reduction)? Or in fact is it because website defacements are no longer as newsworthy as they once were, in other words there has been no real improvement in our controls but we don’t hear about the control failures?
o If the numbers are higher than before, does that necessarily mean our controls are ineffective? Or could it mean that the threats and impacts have increased and we have not kept pace?
• It is practically impossible to measure objectively what could have happened had we not improved our information security controls. The issue is sometimes one of conjecture.
Conclusion
Meanwhile, work on development of an ISO standard on Information Security Management (Measurement) has started from 2005 onward and continues apace. Publication of this standard is expected soon. The standard is intended to help organizations measure and report the effectiveness of their Information Security Management Systems, covering both the security management processes (defined in ISO/IEC 27001) and the security controls (ISO/IEC 27002). The purpose of the Information security management measurements development and implementation process, defined in this Standard is to create a base for each organization to collect, analyse, and communicate data related to ISMS processes. This data is ultimately to be used to base ISMS-related decisions and to improve implementation of ISMS.
Security Metrics is a key tool in the business of Information Security. But it has often been debated that objective measurement of security related parameters is by and large difficult and when possible, rather inaccurate. However, with security having emerged as a design criterion in most organizations, systems and software, and financial consequences of security violations having become extremely high, there is growing acceptance amongst most CISOs and even the CIO/CTOs about the need for security metrics. It is also a prevalent view that these metrics should be aligned to business KRAs.
But the agreement almost ends there and there are differences of opinion regarding many aspects. In most organizations, an independent Information Security stream evolves in due course of time and is often carved out of the IT department. Thus, besides having business KRAs-aligned security metrics, presence of apex level directives is essential as a key facilitator for the security metrics program.
With that in place, the next step would be to prepare an exhaustive body of metrics which cover all areas of the operational landscape. To arrive at the set of metrics that best fit your organization, we need to answer a few very relevant questions:
a. Which metrics are relevant for the organization? Answer to this question will lead to weeding out those metrics which add bulk to the metrics program but no value. In security metrics, more is not necessarily better. Also, there may be a tendency to propose metrics based on the ease of availability, the so called criterion of STTCBM (“Security Things That Can Be Measured”). However, ideally we should like to see a small collection of quantitative values that are a good characterization of the current security state of an organization as well as a measure of its dynamic rate of change (hopefully improvement) over time. For executive audiences this is critical. The best candidates for such metrics should first focus on outcomes as opposed to the policies, people, processes, and technologies that have been put in place to achieve those outcomes. For example: Number of Security Incidents of varying severity for a given period in the entire organization, Mean Time between Security Incidents and Mean Time for closure of a Security Incident.
b. Are these measurable? In the scope of Security Metrics, we have several tangible or objective things such as number of virus incidents or number of people trained etc. And we also have certain intangible things such as level of security awareness, effectiveness of Risk Assessment etc. It is relatively easy to measure tangible aspects. But measuring intangible things poses several challenges and it is easy to give into the temptation of sticking to only those which can be measured. Given the intangible but vital nature of security awareness, it is definitely worth putting effort into the measurement of such subjective factors, rather than relying entirely on easy-to-measure but largely irrelevant objective factors. Measuring anything makes it easier to drive improvements but measuring the wrong things leads to improving the wrong things.
c. What Business goals do they serve? The hard part is not measurement per se but is figuring out what parameters to measure and what needs to be done to make them measurable. Information security is a complex field with ramifications throughout the organization. It is unrealistic to expect to find a few simple measures. It is important to think long and hard about what actually needs to be improved before building a measurement system, or at least before casting it in stone. First of all one should be absolutely clear about the purpose of the measurements, how it will be reported and what use do they serve. We should know who will ‘consume’ them, and what we expect the consumers to do with them. If you have a clear purpose in mind (e.g. to inform management about the information security program, to justify the investment and/or to improve the program’s effectiveness), it will help determine which metrics you need.
Overcoming Challenges
After the above questions have been answered, we then have to initiate the process of data collection from the relevant systems or processes, analyse this data and process it to formulate the metrics. Some challenges may be found at this stage. There may be challenge of getting stakeholders buy in for collecting metrics data from the source(s). And once that is surmounted an even bigger challenges could be automating these metrics.
The concerned departments whose operations come under the scanner may have issues in making the data for metrics available while the Information Security department remains thirsting for information. Nothing paves the way smoother for a Security Metrics program than having direct support from top management. Every security conscious organization should have an apex body or a council where security matters are tabled in a regular periodicity. This forum then serves as the driving force behind not only the Information Security governance and policy implementation processes but also that of the Security Metrics program. The security metrics should be handled by a metrics program manager under the CISO and the process should be periodically audited independently.
Metrics are very good if you can obtain them in an automated way. It is of importance because errors inherent in human intervention can be avoided; also the program becomes sustainable as well as scalable. Another critical aspect is independence. When automated the data would come independently from the source of collection rather than provided by the owner of the source. Essentially this would avoid a conflict of interest. However, automating metrics collection/reporting has its own pitfalls, the main one being a bias towards metrics that can be collected and analyzed in an automated fashion, which implies using data extracted from the IT systems. Unfortunately, some of the most interesting aspects of Information Security are the people and not the systems. For example, the effectiveness of policies and awareness activities can be measured by observing employee's changing behaviors. And unfortunately very few of those changes can be easily measured.
Objective and Relevance
There are many advantages associated with security metrics such as facilitating risk quantification leading to management decisions, optimum resource allocation etc. However, one of the main goals is that metrics should lead to positive change in behavior. While they should focus on generating and presenting data which point to the deficiencies that need to be plugged, it must be remembered that the very behaviors that these metrics want to amend have come into existence not purely out of users uninformed habits. Often, it is because of the way IT is rolled out in a company. And almost always, it is a cultural issue; culture of the organization as also of its people. It is clearly apparent that security is not a technology problem; we may have the most complex mathematics and cryptography; but all the security in the world may not help. Security is a social issue; it is a trust issue. The gaming industry and marketing industry are very adept at manipulating peoples’ behaviors. We may actually need to involve Security Psychologists and may be some marketing people to prepare a security marketing campaign to motivate people to do the right thing. And the right thing is of course; that which has been measured to be the most desirable and effective behavior for the security issue at hand.
Information security, like risk, is a notoriously difficult area to measure, the main problem being how to measure the ‘lack of incidents’. Some concerns in doing this are enumerated below:
• If the information security risk analysis is accurate, and if effective information security controls are implemented, security incidents should be avoided, or at least their number and severity should reduce. (That’s primarily what we’re trying to achieve through information security, though it is not all. There are other important benefits too: strong information security controls improve management’s confidence, making it easier to enter into new business ventures that would otherwise be too risky to consider. For some like financial services, security is absolutely valuable for their core business and therefore a fundamental brand value.)
• If we simply measure the number and severity of incidents, we will have some numbers to play with but what will those numbers actually tell us?
o If the numbers are lower than before we started the information security program, we could claim success but what if the number and severity of incidents had fallen anyway? For example, we see fewer website defacements now than a decade ago: is that because websites are better protected now (control improvement) or because there are fewer hackers actively targeting website defacements (threat reduction)? Or in fact is it because website defacements are no longer as newsworthy as they once were, in other words there has been no real improvement in our controls but we don’t hear about the control failures?
o If the numbers are higher than before, does that necessarily mean our controls are ineffective? Or could it mean that the threats and impacts have increased and we have not kept pace?
• It is practically impossible to measure objectively what could have happened had we not improved our information security controls. The issue is sometimes one of conjecture.
Conclusion
Meanwhile, work on development of an ISO standard on Information Security Management (Measurement) has started from 2005 onward and continues apace. Publication of this standard is expected soon. The standard is intended to help organizations measure and report the effectiveness of their Information Security Management Systems, covering both the security management processes (defined in ISO/IEC 27001) and the security controls (ISO/IEC 27002). The purpose of the Information security management measurements development and implementation process, defined in this Standard is to create a base for each organization to collect, analyse, and communicate data related to ISMS processes. This data is ultimately to be used to base ISMS-related decisions and to improve implementation of ISMS.
Subscribe to:
Posts (Atom)