Security management - setting up audit and account
COMPUTER MONITORING – PROJECT BASED APPROACH
SUMMARY
This is practical guidance on how to implement audit and account.
It is NOT a technical guide. It is directed at IT or security managers who want to persuade corporate executives to up the ante on audit and account or just do it in the first place
The guidance is not intended to be proscriptive, but to show how to develop cost effective options which can be scaled to the requirements of each system to be monitored.
Monitoring must be soundly based on risk analysis and management techniques and backed by a business case. In other words, don’t talk to your corporates on a technical or security basis, they won’t understand. Talk money instead.
It should be introduced to the organisation on a project basis which should fall into two phases: a feasibility study and an implementation phase.
The feasibility study should ask the question: why should we do this and what is the most cost effective way to do it?
The implementation phase should ask and answer the question of how should we do this?
Monitoring, like prevention, can never completely eliminate risk. Nor is it a fit and forget process. Regular reviews of current practice need to be incorporated into the ongoing processes and a feedback loop needs to be built into the daily practice.
INTRODUCTION
Account and audit is often treated as being a low priority in systems security, particularly when other costly defensive controls have already been put in place.
The argument often goes that since nothing has happened to the system, why employ monitoring measures?
The irony is that without monitoring there is no chance of detecting the system breaches which justify its usage or the employment of other (additional) controls.
This guide takes the view that while prevention is the ideal, detection is a must.
IOW, it is unavoidable that systems will experience security breaches but the sooner the breaches can be detected and plugged the better.
Additionally, the information gathered on breaches may provide useful data for blocking future attacks, for pursuing legal routes or other intelligence (e.g. if you can identify companies who might have gained competitive advantage or are actively seeking it by stealing your data).
Having said this, monitoring has to be
Commensurate with the perceived threat (business threat not technical i.e. how much money/reputation/share value will the business lose?)
Represent value for money
Affordable and;
Easy to implement and maintain
This means that monitoring should
Be justified by a business case
Based on sound risk analysis and management judgements
Be balanced against the cost and effort of introducing and implementing other controls.
Be supportable in terms of human resources and ongoing running costs
This will lead to a pick and mix approach with regard to detection mechanisms depending on the particular nature of the threats being addressed.
APPROACH
Monitoring (monitoring) should be introduced on a project basis.
Project Management techniques should be scaled to the requirements of the organisation.
The project should fall into two phases
1) Feasibility study
Threat Assessment
Vulnerability Analysis
Technical Infrastructure Gap Analysis
Identification of controls
Identification of tools and techniques
Staffing and training requirements
Contractual services requirements (optional)
Overall budget requirements
Employee monitoring policy
Incident investigation and response procedures
Reporting structure
Recommendations report
2) Implementation Phase
Tender for contractual services (optional)
Installation of tools
Staff allocation and training
Employee awareness exercise
Initiation and ‘base lining’ of process
Initiation of reporting structure
Ongoing maintenance and review (outside project scope)
The requirements for these two phases are detailed below.
The project board would ideally consist of the HR director, the Head of Security and the Head of IT Operations. The project manager should be someone familiar with network and systems operations and security but not necessarily a specialist (avoids imputation of empire building).
FEASIBILITY STUDY
1) Threat Assessment
The threat assessment should consist of the following:
The intent and sophistication level of the attackers
External system connections (i.e. downstream liabilities)
Effort spent on this exercise should be appropriate to the sensitivity/criticality of the system.
Effort spent should also reflect the security stance of the organisation and the nature of the business implemented on the system.
This in turn determines the purpose of monitoring in the organisation (whether it is primarily for deterrence, detection, forensics, intelligence, future prevention, current cure) and this will be reflected in the choice and placement of monitoring controls.
VULNERABILITY ANALYSIS
The aim of this analysis is to produce a list of known or likely technical vulnerabilities that would commonly be exploited by the sources of the threats identified in the threat analysis.
The vulnerability analysis is a technical appraisal of the systems configuration. This may be done formally or informally. A good starting place is the SANS institute top 20 to get a run down on the best preventative and detective methods for guarding the various items on your infrastructure. http://www.sans.org/top20/. Or else look at the specific sites of your suppliers.
A formal approach to vulnerability analysis with the purpose of refining the tactical deployment of monitoring would include carrying out security audits, software tool driven vulnerability analysis and/or formal penetration testing.
An informal approach could range from examining the known configuration of the system in the light of common exploits to carrying out informal penetration tests by appropriately trained internal staff.
This examination should be scaled to the size and complexity of the systems.
TECHNICAL INFRASTRUCTURE GAP ANALYSIS
It would be very unusual to have a system with no tools for monitoring incorporated into it and no usage of these tools in practice.
It is more usual to find that various forms of logging have been switched on, but that the logs are not being examined (except informally to resolve systems and network problems) nor archived.
Therefore, the logging that has been incorporated into the system should be measured against the threats and vulnerabilities identified in order to determine what is and what is not being done on the system.
You should look at all monitoring options even the most sophisticated (IPS) even if you think they are OTT, because sometimes one OTT feature on your system might save a whole heap of other controls sometimes you'd be better off selling them back to the company for a different product.
Also get the basics right ie. Synchronise your system clocks to an external time source, archive your logs offline asap and keep the logs for as long as you think you need them (which also means no longer than you need them). This could be up to 7 years for financial transactions. Check out the legal requirements.
The reason for looking at all requirements is that it is possible that a sophisticated monitoring solution has been supplied, but is either not being used or indeed is overkill for the system in question.
This work should be carried out in conjunction with systems and network administrators. It may also be useful have external consultancy for larger systems
This exercise will also identify areas where other defensive controls have been applied which may make the implementation of monitoring measures nugatory (e.g. if staff policy forbids visiting pornographic sites and web filtering with ongoing updates has been applied to prevent this then it may be deemed an acceptable risk not to monitor for this behaviour)
Some measures (e.g. synchronisation of clocks) form the basis of monitoring and these must clearly identified as the baseline.
IDENTIFY CONTROLS
Monitoring techniques differ according to what is being protected and what it is being protected against.
Monitoring needs to be considered in conjunction with other possible controls.
Monitoring should be applied to each system barrier as follows
The network perimeter (external routers and firewalls)/other external connections
Firewalls
Internal network resources (where infiltration is a recognised threat)
Hosts (where the threat is exfiltration)
Applications
Client/user Interface
Mobile/removable devices/media
Each of these areas faces specific technical threats.
The type of technical threat at each point likely to be faced by a system relates to the threat assessment and the vulnerability of the configuration (i.e.) what attacks are likely to be launched and how successful would these potentially be given the known vulnerabilities of the current systems configuration and what are the business aims of the attackers and therefore the likely damage to the business of the organisation.
For example, an organisation doing ‘innocuous’ work would probably only be the target of ‘script kiddies’, but an organisation involved with the military would be a target for foreign intelligence services/terrorists – an inbetween scenario might be a medlab doing or perceived to be doing animal testing and the target of hacktivists. This would affect the sophistication level of the attack in most cases and the cost and sophistication of the controls.
This in turn will affect the level and sophistication of the monitoring and analysis required.
The gap analysis will reveal if the system can through the application of current resources adequately monitor and detect attacks or if additional monitoring needs to be applied at a particular point.
In many cases, it may simply be a matter of properly applying human resources to monitor and analyze the results being recorded by already available systems tools.
However, it should also be considered whether a more robust systems configuration would successfully counter these threats (e.g. hosting web based applications on an Apache server as opposed to MS IIS) or if a combination of defensive controls to harden the systems configuration should be employed alongside effective monitoring measures.
The end result of this exercise should be a list of potential controls consisting of monitoring measures, alternative defensive controls and complementary defensive controls.
CDATA[ Consider coordinating efforts with other businesses in the same area which face the same threat. E.g. catalogue companies and online shopping malls all face the problem of e-fraud. Collating information (source anonymised) can reveal patterns which can be used to track down fraudsters. ]
The controls may be applied on the basis of
Always on
Sometimes on
To be used only where ‘mouse droppings’ have been uncovered (i.e. signs of possible breaches)
The frequency of analysis and reporting also needs to be considered.
This exercise should be carried out in so far as possible on the conceptual level rather than focusing down on particular tools. i.e. ‘sniffing should be considered on the network segment A ’ as opposed to ‘let’s use snort.exe to do such and such’.
However, the final outcome of this exercise will be constrained by practical considerations dealt with the following sections in particular the vexed question of data retention periods.
IDENTIFY TOOLS AND TECHNIQUES
Having identified conceptually what may be required, the actual tools and techniques that should be used for monitoring should be identified in detail.
This process will consist of:
An overview of available tools in the marketplace via the Internet
Attendance at Infosec exhibitions as an opportunity for no obligation meetings with suppliers and to obtain literature on the subject
From this process, a list of possible tools can be identified.
In addition, this research will identify the current techniques being applied to monitoring, at what points they are implemented on systems and networks, how they work and what they are intended to protect against.
It is recommended that an overview of common hacking techniques be undertaken in the light of monitoring methods uncovering not just the potential of monitoring to identify these attacks but also the potential problems that monitoring faces.
e.g. IDS/IPS may not be effective against stealth techniques (such ‘nmap –sU –O –T 0’ or ‘teardrop’ attacks) and in some cases it can leave systems vulnerable to (D)DOS attacks (‘fraggle’) because the IDS becomes the ‘cork in the bottle’ as it is unable to cope with the traffic volumes.
Finally, particular attention should be paid to the question of archiving information. While this should have been covered at the conceptual level, the practicalities of storing large amounts of information may overturn these principles.
Unless the organisation is willing to engage in extensive trends analysis or exhaustive forensics/intelligence work long term retention of the data is neither practical nor desirable. Better just to fix the problem and move on.
Data retention periods should be limited by what is intelligently considered may be achieved with retained data. For example, email and internet monitoring data is worth retaining longer term than daily system logs because the results can be employed meaningfully where there is evidence of abuse more readily.
Data retention also means data review and deletion i.e. only ‘interesting’ data should be retained and then only if it is going to be used .monitoring has to make gains in the short to medium term for it to be effective. Long term gains from monitoring are out of the reach of most organisations.
Most importantly, data retention means data retention offline. On line data retention opens the organisation to the possibility of the data logs being altered maliciously or accidentally rendering meaningless the monitoring process.
Offline options include paper logs, write only media and computing facilities which are kept offline except when transferring data.
In the case of incident response, it will include as accurate records as possible of the actual state of the computers at the time the incident was discovered including traditional forensics info (finger prints).
STAFF ISSUES
For each tool and technique identified, there will be associated commitment of staff time and a requirement to develop staff into new roles.
In some larger organisations, this may mean developing a different career track for staff giving a team of staff hands on responsibility for day to day systems security operations, of which monitoring will form a large part.
The human resources impact of introducing each aspect of monitoring identified has to be clearly described so that management are aware of the level of commitment they are required to give to staffing and training to make monitoring work for their systems.
CONTRACTS
In some instances, management may not have the human resources available to develop monitoring as it should be.
Where this is the case, they will then need to consider contracting out all or part of the monitoring service.
Many larger organisations already have managed services for network or host administration in place.
Farming out monitoring to the companies involved would require renegotiating the contract ( as a result of the gap analysis). Management should develop an ‘intelligent customer’/’virtual manager’ function to coordinate and report on these activities and to make changes where the threat profile alters significantly.
MONEY MONEY MONEY
Having identified potential controls, the tools and techniques which need to be employed to make those controls effective and the staffing, training and other services required to implement the tools and techniques on the system, it becomes possible to identify what the budget requirements for monitoring are both for implementation and in terms of running costs.
It is quite likely that the budget will on the first iteration of this process be ‘unaffordable’.
At this point, the process has to be repeated from the conceptual identification of controls through to a new cost calculation.
A lot of CREATIVITY is needed at this point.
Always put it in money terms eg. X% of the cost of Y system per annum will prevent $$$$ damage
In particular, this should concentrate on the following areas:
Alternate controls particularly robust design.
Automating the process of monitoring where possible to reduce staffing and training costs
Identifying where monitoring measures unnecessarily overlap (e.g. is IDS required on the external router if the firewall already carries out ‘stateful’ inspection and contents filtering of packets)
At no point, is it thought that the editing of monitoring measures will result in a system which has no monitoring applied to it. Better to resign now than become the focus of blame for a security breach you have not been given the means to prevent. Who needs that on their CV???
The question that should be asked of Senior Management is not do we use monitoring but how to make monitoring both affordable and cost effective as a countermeasure.
EMPLOYEE MONITORING
Various countries have legal requirements that the privacy of data relating to individuals be respected.
Monitoring by its nature builds up profiles of individual’s behaviour on a system and therefore this data falls under these requirements.
IMO it is good practice to adhere to these guidelines anyway. Apart from anything else it is polite
In brief, employees should be informed
What activities are monitored
Why their activities are monitored
How they are monitored
When they are monitored
Who has access to the information
How long the information is kept
What may be done with the information (e.g. in support of disciplinary action)
In addition,
Employees should sign that they understand the monitoring process
Monitoring should be automated where possible and concentrate on statistical methods to detect anomalies rather than focusing suspicion on individuals
Only personnel and security staff (and trusted and cleared IT staff where required) should be allowed access to individual data
Covert monitoring should not be undertaken except where a serious crime or+= threat to health and safety is suspected to be ongoing (ethically speaking spying on someone who is only doing a bit of online shopping is way OTT as is firing them for doing so)
Managers should not be able to directly request monitoring of specific employees except where they suspect something very serious is going on.
Decide to whom Monitoring statistics should be made available – they could be a useful awareness tool e.g. monitoring stats by department might put the ‘scare’ into some offenders.
As part of the feasibility study, an Employee Monitoring policy should be drawn up for the entire organisation.
To save time this should cover all aspects of monitoring (e.g CCTV, card swipe) not just IT based.
Incident Investigation and Response Procedures
monitoring does not often uncover security breaches in real time.
However, where it does so incident response procedures need to be in place.
In addition, some organisations will wish to use monitoring tools to gather intelligence or forensics data.
This area of work is very complex both legally and in terms of the sophistication of techniques required (which in turn implies additional staff and training issues). It should not be undertaken by non-experts.
Organisations will therefore need to consider whether they wish to include this in their monitoring armoury.
Given the cost and complexity of doing so, most organisations unless heavily involved in gov/military operations are unlikely to go down this route.
However, some level of investigation will be needed in order to determine if additional controls or procedures are required in order to plug gaps.
Most organisations should be able to do this although in the case of serious breaches they wish to seek outside advice and consultancy.
These requirements will need to be identified and written up.
REPORTING
The final aspect of monitoring to be considered is the reporting structure.
It is important that the results of log analyses are reported and acted on in an appropriate and timely fashion.
This requires a threefold reporting line.
To Infosec/Security personnel – incidents, breaches, suspicious activity
To Operational Management – incidents, breaches, network problems and issues arising from the application of monitoring
To Personnel – employee abuses
The reports should be come the basis for recommendations on
Infosec/Security – further investigation, policy/procedural change recommendations
Operational Management – fire fighting, configuration changes
Personnel – further investigation, disciplinary action
The reporting structure should be agreed in outline before implementing monitoring and roles and responsibilities in terms of analysis, reporting and recommending action should be agreed in principle.
RECOMMENDATIONS REPORT
The information gathered during the feasibility study should be written up in a recommendations report which becomes the input for the next phase of the project.
On the basis of the recommendations report, commitment of resources to the next phase of the project and ongoing budgetary requirements should be sought from senior management as represented by the Project Board.
The Employee Monitoring Policy and the Incident Investigation and Response Procedures must be signed up to by personnel, security and operations management .
Operations, security and personnel management should agree to the reporting structure.
IMPLEMENTATION
1)Tender for Contracted Services (Optional)
If either the use of skilled contractors or managed services has been identified as a requirement for the introduction and ongoing implementation of Monitoring in the organisation, these should be tendered for.
Alternatively, if managed service providers are already in place, negotiations should commence to add to the contract where necessary requirements for monitoring.
The service providers will become responsible for any configuration, operational or personnel changes required.
An ‘intelligent customer’ function should be developed to coordinate and report on the results of this work and on ongoing monitoring.
2)Installation of Tools
The tools identified for monitoring work should be procured and installed.
It may be possible to include some of this work under the heading of tender for contracted services as some suppliers not only install the tool but help with its initial base lining to the requirements of the system.
All tools should be tested for their impact on resources both staff and computer.
3)Staff Allocation and Training
Staff should be ‘recruited’ into their new roles internally or offered employment as required.
The staff brought into these roles should have a technical information systems background.
Training of staff should concentrate on four areas
Ethical hacking and controls
Implementation, configuration and use of monitoring tools
Forensics
Incident response
Training may consist of a combination of formal coursework (and qualifications if this level of assurance is required) and/or ‘knowledge transfer’ on the job from consultants/contractors/suppliers.
It should be recognised that in smaller organisations the monitoring role may be additional to the day to day job and priorities adjusted
In larger organisations, the monitoring role (combined with other technical security functions such as vulnerability analysis and configuration hardening) will become a separate career path.
In very large organisations, whole teams might be dedicated solely to monitoring and incident response.
4)Employee Awareness Exercise
Before monitoring is introduced to an organisation, employees should be informed of how it will apply to them.
This can be done via a security awareness exercise (which is a useful excuse to remind them of their other security based obligations).
However, it is sufficient to use normal communications channels to inform them of any changes to policy and procedures.
Employees must sign an Acceptable Usage policy that states monitoring of their work will occur.
5)Initiation and ‘Base lining’ of the Process
There is a tendency in monitoring to switch everything and then on being overwhelmed by the amount of data generated to switch everything off again.
Even having identified the monitoring controls to be employed and the tools and techniques to implement them, it is important to utilise those tools intelligently.
What is switched on or off should be determined by what the overall philosophy of monitoring in the organisation is. This is determined by the security stance of the organisation and the sources of threat identified during the Threat Analysis in the Feasibility study.
For example, an organisation which is primarily vulnerable to net based attacks will probably concentrate on network intrusion detection methods combined with configuration changes to harden the perimeter.
While an organisation which has a heavy applications load will be more interested in host based intrusion detection (e.g. using file checksums to detect underlying changes in the operating system of applications using software such as tripwire) combined with applications hardening techniques.
The end result of the above is that as a result of the feasibility study and the information gathered during the initial implementation of the toolset and the deployment and training of staff, the way the tools are used should reflect
A selected proportion of the monitoring controls
A deployment of alternate (defensive) controls which reduce the need to monitor at particular points
From those controls, a selection from all the potential tools in the range
From those tools, a selection of the potential range of facilities available to be deployed
From the data generated, a selection of the information to be analysed, retained and reported on (see next section)
It may take several months to work out the optimal configuration to achieve the aims of the monitoring philosophy of the organisation and this will be achieved through the reporting process.
6)Initiation of Reporting
Following on from point in the previous section, an agreed reporting structure shall be implemented.
As soon as possible, the meaningfulness of those reports should be determined on the basis that reports which don’t initiate the possibility of change are not achieving the aims of monitoring.
It may be argued that if there is nothing found, there is nothing to be found. It is more likely that if nothing is found, the looking is not being done in the right place.
The configuration and deployment of tools in information gathering should be refined or changed as a result of this feedback.
ONGOING MAINTENANCE AND REVIEW
Although it is outside the scope of the initial project, it must be considered monitoring is not a fit and forget operation.
Regular reviews of the monitoring structure of the system should be built into ongoing operational management.
CONCLUSIONS
Monitoring is a must for any organisation with computer systems.
However, monitoring is not a one size fits all process. It needs to be scaled to the size and criticality of the computer systems and perhaps more importantly to the organisation’s budget.
More importantly still, the way in which monitoring is introduced to an organisation needs to be scaled to the organisation’s requirements.
Appropriate use of project management methodology and an intelligent approach to selecting monitoring controls to fit alongside other security controls will go a long way to ensuring that the requirements of scale and cost effectiveness are met.
A bit of luck is probably required too.
