Why Can't We All Just Get Along? Table

1.00	3.1.1	Information security policy document	Stays; as the management will need to disseminate its commitment and approach to the resultant policy regardless of the motivation.
1.00	3.1.2	Review and evaluation	Stays; again a management forum ensuring there is a clear direction and visible management support and responding to changes is still applicable, regardless of motivation.
1.00	4.1.1	Management information security forum	Stays; see above.
1.00	4.1.2	Information security coordination	Stays; as management will need to someone acting as their representatives from relevant parts of the organization to coordinate the implementation of the policy.
1.00	4.1.3	Allocation of information security responsibilities	Stays; someone again will need to determine responsibilities for the protection of individual assets and for carrying out specific security processes that were clearly defined by management and their representatives.
1.00	4.1.4	Authorisation process for information processing facilities	Stays; as management will need an authorisation process in place for any new information processing facility. Including all new facilities such as hardware and software.
1.00	4.1.5	Specialist information security advise	Stays; If bad guys are removed from the equation, there will still be a need for people to get assistance, especially in understaffed/overwhelmed companies.
1.00	4.1.6	Co-operation between organizations	Stays; but primarily for telecommunication companies, and information service providers, ISPs, to ensure that appropriate action can be quickly taken and advice obtained, in the event of an outage, as availability is a known cornerstone of security.
1.00	4.1.7	Independent review of information security	Stays; this is to provide assurance that the policy is feasible and effective, and having a third parties input can be valuable for gaining perspective.
0.50	4.2.1	Identification of risks from third party access	50% Goes, risks from third party access are no longer a factor, however 50% stays as third party contractors working onsite can still create unintentional outages, as anyone working with a VAR can most likely attest.
1.00	4.2.2	Security requirements in third party contracts	Stays; again this will refer to outages.
1.00	4.3.1	Security requirements in outsourcing contracts	Stays; see above.
1.00	5.1.1	Inventory of assets	Stays; as a component of a Business Impact Analysis this is will be critical, remember that Business Continuity and Disaster recovery are still issues even if not driven by malicious activity.
1.00	5.2.1	Classification guidelines	Stays; as an information classification scheme or guideline; which is intended to determine how the information is to be handled and protected need not only be based on sensitivity, but also can include value.
1.00	5.2.2	Information labelling and handling	Stays; defining the information labelling and handling in accordance with the classification guidelines will be a critical part of a classification procedure.
1.00	6.1.1	Including security in job responsibilities	Stays; defining responsibilities for the protection of particular assets will play a role in any DR/BC component of a program.
1.00	6.1.2	Personnel screening and policy	Stays; while nobody is going to be dishonest, verification checks on permanent staff will still need to be carried out at the time of job applications. This is to prevent against people over assessing the skill
0.50	6.1.3	Confidentiality agreements	50% Goes, nobody is trading or selling secrets and therefore Confidentiality or non-disclosure agreements would not be needed. 50% Stays; as this could apply to pricing, nobody would want to make a customer jealous inadvertently by offering better pricing to a larger customer.
1.00	6.1.4	Terms and conditions of employment	Stays; employees will still need to know the conditionality of their employment to meet responsibilities.
1.00	6.2.1	Information security education and training	Stays; as employees of the organization and third party users will need to learn about where to store files so they are properly backed up in the case of a drive failure and will therefore need to receive appropriate Information Security training and regular updates in organizational policies and procedures.
1.00	6.3.1	Reporting security incidents	Stays; regardless of the motivation it is still important to report security incidents such as outages through appropriate management channels as quickly as possible.
1.00	6.3.2	Reporting security weaknesses	Stays; a formal reporting procedure for users to report business continuity related threats to systems or services is still going to be required.
1.00	6.3.3	Reporting software malfunctions	Stays; This is an easy stay, of course it would remain important to report any software malfunctions.
1.00	6.3.4	Learning from incidents	Stays; any time the ability to learn about the types, volumes and costs of incidents and malfunctions in a quantifiable way that is able to monitored.
1.00	6.3.5	Disciplinary process	Stays; if an employee has violated organizational security policies and procedures even just by apathy or neglect, there will still need to be formal disciplinary process in place. This process will still be a deterrent to employees who might otherwise be inclined to disregard security procedures.
0.00	7.1.1	Physical Security Perimeter	Goes, with no theives there will not be a need for physical border security.
0.00	7.1.2	Physical entry Controls	Goes, again thieves will not be trying to get their hands on any assets.
0.00	7.1.3	Securing Offices, rooms and facilities	Goes, again thieves will not be trying to get their hands on any assets.
0.00	7.1.4	Working in Secure Areas	Goes, again thieves will not need security controls for third parties or for personnel by placing them into the secure area.
0.00	7.1.5	Isolated delivery and loading areas	Goes, with no theft we do not need a delivery area and information processing area are isolated from each other to avoid any unauthorised access.
1.00	7.2.1	Equipment siting protection	Stays, we still need controls to minimize risk from potential threats such as fire, smoke, water, dust, vibration, chemical effects, electrical supply interfaces, electromagnetic radiation, and floods. Also there is good justification for a policy towards eating, drinking and smoking on in proximity to information processing services.
1.00	7.2.2	Power Supplies	Stays; equipment will need to be protected from power failures by using permanence of power supplies such as multiple feeds, uninterruptible power supplies, and backup generators to prevent outages.
1.00	7.2.3	Cabling Security	Stays, power and telecommunications cable carrying data or supporting information services will still need to be protected from damage.
1.00	7.2.4	Equipment Maintenance	Stays; it is still important to ensure that the equipment is maintained as per the supplier’s recommended service intervals and specifications and that logs are kept for all suspected or actual faults and all preventive and corrective measures. Also it will still be equally important to know if the equipment is covered by insurance, and if the insurance requirements are satisfied.
1.00	7.2.5	Securing of equipment off premises	Stays; there will still need to be equipment usage outside an organization’s premises for DR, that will need to have backup procedures, especially for in the event of the primary site undergoing an incident like a power outage.
0.00	7.2.6	Secure disposal or re-use of equipment	Goes; as information is no longer has a threat of being stolen, storage devices containing sensitive information will not have to be physically destroyed or securely over written.
0.00	7.3.1	Clear Desk and clear screen policy	Goes, as automatic computer screen locking facility is no longer going to need to be enabled, nor will we have to worry when leaving any confidential material around, as no one will steal it.
1.00	7.3.2	Removal of property	Stays, when equipment, information or software go offsite without appropriate authorization there may not have been the appropriate thought as to whether it could be lost.
1.00	8.1.1	Documented Operating procedures	Stays; It should not be to avert hackers that identifing operating procedures such as backing up systems and equipment maintenance are defined and these procedures are documented and used.
1.00	8.1.2	Operational Change Control	Stays; again programs running on production systems being subject to strict change control i.e., any change to be made to those production programs need to go through the change control authorisation has more to do with the creation of a solid code production and stable code over defeating hackers.
1.00	8.1.3	Incident management procedures	Stays; When a disaster occurs on a critical server an Incident Management procedure to addresses the incident management responsibilities, and respond according to such guidelines will be equally valuable if the damage was intentional or otherwise.
1.00	8.1.4	Segregation of duties	Stays; Although the intent behind duties and areas of responsibility being separated is to reduce opportunities for unauthorized modification or misuse of information or services, the result of keeping this component is that it avoids the "What if the System Administrator gets hit by a bus?" problem that can occur if cross training doesn't.
1.00	8.1.5	Separation of development and operational facilities	Stays; to not affect the services offered by the production network keeping the development and testing facilities isolated from operational facilities is key to integrity and availability. For example development software should run on a different computer to that of the computer with production software.
1.00	8.1.6	External facilities management	Stays; as any Information processing facility managed by external company contains risks especially related to availability. The risks associated with such management is will still need to be discussed with the third party and appropriate controls incorporated into the contract.
1.00	8.2.1	Capacity Planning	Stays; Capacity demands will still need to be monitored and projections of future capacity requirements will need to be made to ensure that adequate processing power and storage are available.
1.00	8.2.2	System acceptance	Stays; System acceptance criteria will continue to need to be established for new information systems, upgrades and new versions. Suitable tests will still need carried out prior to acceptance to ensure availability and integrity.
0.00	8.3.1	Control against malicious software	There will not be any malicious software, or any usage of unauthorized software.
1.00	8.4.1	Information back-up	Stays; The Back-up of essential business information such as production servers, critical network components, configuration backup etc., will still need to be taken regularly to ensure integrity and availiability.
1.00	8.4.2	Operator logs	Stays; the Operational staff would still benefit their troublseshooting by maintaining a log of their activities such as name of the person, errors, corrective action etc.,
1.00	8.4.3	Fault Logging	Stays; faults still need to be reported and well managed. This includes corrective action being taken, review of the fault logs and checking the actions taken.
0.50	8.5.1	Network Controls	50% Stays; There will need to be responsibilities and procedures for management of remote equipment, including equipment in user areas were established. 50% Goes; There will not be any special controls to safeguard confidentiality and integrity of data processing over the public network and to protect the connected systems.
1.00	8.6.1	Management of removable computer media	Stays; There will still be a need for a procedure for management of removable computer media such as tapes, disks, cassettes, memory cards and reports, but not due to a loss by theft, but only to keep track of inventory.
0.00	8.6.2	Disposal of Media	Goes; as the media that are no longer required will not need to be disposed off securely and safely.
0.00	8.6.3	Information handling procedures	Goes; there will not need to be a procedure for handling the storage of information. This procedure is intended to address issues such as information protection from unauthorized disclosure or misuse which will no longer be an issue.
0.00	8.6.4	Security of system documentation	Goes; the system documentation will not need to be protected from unauthorized access.
0.00	8.7.1	Information and software exchange agreement	Goes; There will be less of a need for formal or informal agreement between the organizations for exchange of information and software. The agreement would not have to addresses the security issues based on the sensitivity of the business information involved.
1.00	8.7.2	Security of Media in transit	Stays; security of media while being transported will still be taken into account. The media will still need to be protected from corruption.
0.50	8.7.3	Electronic Commerce security	50% Goes; Electronic commerce will not need to be well protected and controls will not need to be implemented to protect against fraudulent activity, and disclosure or modification of information. 50% Stays; as there still can be contract disputes over misunderstandings over the contracts content.
1.00	8.7.4	Security of Electronic email	Stays; there will still be a need for a policy in place for the acceptable use of electronic mail. While there will no longer be a need for antivirus checking, isolating potentially unsafe attachments, spam control, anti relaying, etc. there will still need an understanding reached with employees that work email is not for personal use, as some users may not be aware of this.
0.00	8.7.5	Security of Electronic office systems	Goes; there will not be a need for an Acceptable use policy to address the use of Electronic office systems.
1.00	8.7.6	Publicly available systems	Stays; there will still need to be a formal authorization process in place for the information to be made publicly available. This will be used for QA, as well as approval from Change Control which includes Business, Application owner etc.,
0.00	8.7.7	Other forms of information exchange	Goes; as policies, procedures or controls in place to protect the exchange of information through the use of voice, facsimile and video communication facilities will not be needed.
1.00	9.1.1	Access Control Policy	Stays; The business requirements will not need access control defined and documented, as no malicious users will attempt to breach the network, but a policy will still need to define what is going to be accessible, just to control changes.
1.00	9.2.1	User Registration	Stays; there will still need to be a formal user registration and deregistration procedure for granting access to multi-user information systems and services to control changes.
1.00	9.2.2	Privilege Management	Stays; the allocation and use of any privileges in multi-user information system environment will still need to be restricted and controlled for change control and to protect against ernest intended changes from having unintended consequences.
0.00	9.2.3	User Password Management	Goes; the allocation and reallocation of passwords will not need to be controlled through a formal management process.
1.00	9.2.4	Review of user access rights	Stays; there will still need to be a process to review user access rights at regular intervals, again to ensure the process accounts for skill levels.
0.00	9.3.1	Password use	Goes, as guidelines for selecting and maintaining secure passwords will not be an issue.
0.00	9.3.2	Unattended user equipment	Goes; as users and contractors will not need to be made aware of the security requirements and procedures for protecting unattended equipment, as well as their responsibility to implement such protection, as nobody will be attempting to take advantage of open connections.
1.00	9.4.1	Policy on use of network services	Stays; there will still need to be a policy that addresses concerns relating to networks and network services such as: Parts of network to be accessed, Authorization services to determine who is allowed to do what, Procedures to protect the access to network connections and network services, as authorization will still be a factor.
0.00	9.4.2	Enforced path	Goes; There will not be a need for a control that restricts the route between the user terminal and the designated computer services the user is authorised to access, as people should no longer be poking outside of their authorized systems by using injected routing.
0.00	9.4.3	User authentication for external connections	Goes; there will not need to be authentication mechanism for challenging external connections.
1.00	9.4.4	Node Authentication	Stays; connections to remote computer systems that are outside organisations security management will still need to be authenticated to prevent accidental routing issues.
1.00	9.4.5	Remote diagnostic port protection	Stays; as accesses to diagnostic ports will still need to be securely controlled to protect against erronous access and modifications.
1.00	9.4.6	Segregation in networks	Stays; the network (where business partner’s and/ or third parties need access to information system) is segregated using perimeter security mechanisms such as firewalls to prevent unintended changes as well as to make for easier VPN connections as networks would be arranged not to overlap.
1.00	9.4.7	Network connection protocols	Stays; network connection control for shared networks that extend beyond the organizational boundaries will need to be maintained.
1.00	9.4.8	Network routing control	Stays; to enforce network controls to ensure that computer connections and information flows do not breach the access control policy of the business applications. This is often essential for networks shared with non-organisations users.
1.00	9.4.9	Security of network services	Stays; as the organization, as a clear description of security attributes of all services used is provided would prove benificial for network management.
1.00	9.5.1	Automatic terminal identification	Stays; as there will still be a need for accountability via an automatic terminal identification mechanism is used to authenticate connections.
1.00	9.5.2	Terminal logon procedures	Stays; as there will still be a need for accountability for the procedure in place for logging in to an information system.
1.00	9.5.3	User identification and authorisation	Stays; as it would still help with accountability to assign a unique identifier to every user such as operators, system administrators and all other staff including technical.
0.00	9.5.4	Password management system	Goes; as password management system would not need to be in place.
1.00	9.5.5	Use of system utilities	Stays; the system utilities that comes with computer installations, but may override system and application control will still need to be tightly controlled to prevent misconfigurations.
0.00	9.5.6	Duress alarm to safeguard users	Goes; there will no longer be a need for a duress alarm for users who might be the target of coercion.
1.00	9.5.7	Terminal timeout	Stays; Just from a resource stand point it seems logical to maintain a procedure by which inactive terminal in public areas to be configured to clear the screen or shut down automatically after a defined period of inactivity.
1.00	9.5.8	Limitation of connection time	Stays; Just from a resource stand point it seems logical to put a restriction on connection time for high-risk applications.
1.00	9.6.1	Information access restriction	Stays; as there will still be a need for accountability when accessing an application by various groups/ personnel within the organization as defined in the access control policy per the individual business application requirement and to ensure access is consistent with the organization’s Information access policy.
1.00	9.6.2	Sensitive system isolation	Stays; sensitive systems will be easier to maintain with an isolated computing environment such as running on a dedicated computer, share resources only with trusted application systems, etc.
1.00	9.7.1	Event logging	Stays; as audit logs recording exceptions and other security relevant events produced will aid in assisting in future investigations and access control monitoring.
1.00	9.7.2	Monitoring system use	Stays; so long as access is restricted to prevent changes out of change control there should be procedures for monitoring the use of information processing facility. The results of these monitoring activities will need to be reviewed regularly.
1.00	9.7.3	Clock synchronisation	Stays; the computer or communication device will need to use a real time clock, it should be set to an agreed standard such as Universal coordinated time or local standard time to aid in troubleshooting anomolies.
1.00	9.8.1	Mobile computing	Stays; a formal policy will still need to take into account the risks of working with computing facilities such as notebooks, palmtops etc., especially in unprotected environments as a part of the access policy to protect against unintended changes from being made out of change control.
1.00	9.8.2	Teleworking	Stays; any policy, procedure and/ or standard to control teleworking activities will need to be maintained to consistantly enforce the AUP and ACP.
1.00	10.1.1	Security requirements analysis and specification	Stays; all of the security requirements incorporated as part of business requirement statement for new systems or for enhancement to existing systems will need to be identified and should reflect business value of information assets involved and the consequence from failure of Security.
1.00	10.2.1	Input data validation	Stays; regardless of how ideal the user base is, data input to application system always needs to be validated to ensure that it is correct and appropriate.
1.00	10.2.2	Control of internal processing	Stays; areas of risks will always need to e identified in the processing cycle and validation checks that are included. This is to ensure the data that has been correctly entered isn't corrupted by processing errors.
1.00	10.2.3	Message authentication	Stays; Message authentication will still be required to detect the corruption of the contents of the transmitted electronic message.
1.00	10.2.4	Output data validation	Stays; the data output of application system will need to be validated to ensure that the processing of stored information is correct and appropriate to circumstances.
0.00	10.3.1	Policy on use of cryptographic controls	Goes, as there will not be a need for a Policy in use of cryptographic controls for protection of information.
0.00	10.3.2	Encryption	Goes, as encryption techniques will not be used to protect the data.
1.00	10.3.3	Digital Signatures	Stays; Digital signatures can still be used to protect the integrity of electronic documents.
1.00	10.3.4	Nonrepudiation services	Stays; non-repudiation services can be used, where it might be necessary, to resolve disputes about occurrence or non-occurrence of an event or action.
0.00	10.3.5	Key management	Goes; As encryption will not be required there will not be a need for a management system is in place to support the organization’s use of cryptographic techniques.
1.00	10.4.1	Control of operational software	Stays; As mentioned there will be controls in place for the implementation of software on operational systems to minimise the risk of corruption of operational systems.
1.00	10.4.2	Protection of system test data	Stays; system test data will need to be protected and controlled, to ensure the integrity of the tests, and while testing there is no need potentially leak information.
1.00	10.4.3	Access Control to program source library	Stays; There should still be strict controls in place over access to program source libraries to reduce the potential for corruption of computer programs.
1.00	10.5.1	Change control procedures	Stays; as mentioned strict control procedures will need to be in place over implementation of changes to the information system to minimise the corruption of information systems.
1.00	10.5.2	Technical review of operating system changes	Stays; again as part of any development life cycle there is a need for processes or procedures to be in place to ensure application system is reviewed and tested after change in operating system.
1.00	10.5.3	Technical review of operating system changes	Stays; again restrictions in place to limit changes to software packages is a component of change control, and all changes will still need to be clearly tested and documented, so they can be reapplied if necessary to future software upgrades.
0.00	10.5.4	Covert channels and Trojan code	Goes; there will not be any covert channels and Trojan codes will not be introduced into new or upgraded systems.
1.00	10.5.5	Outsourced software development	Stays; there will still be a need for Licensing arrangements, escrow arrangements, and contractual requirement for quality assurance controls in place when outsourcing software.
1.00	11.1.1	Business continuity management process	Stays; as addressed already a managed process in place for developing and maintaining business continuity throughout the organization is a large component of what will stay as the business will still be needed for continuity.
1.00	11.1.2	Business continuity and impact analysis	Stays; events that could cause interruptions to business process are a major component of the security program and will still need to be identified. A risk assessment will need to be conducted to determine impact of such interruptions, as well as a strategy plan based on the risk assessment results to determine an overall approach to business continuity will help the organization prioritize events in the continuity planning as an electrical outage or flood would be just as disasterous in this environment.
1.00	11.1.3	Writing and implementing continuity plan	Stays; plans will need to be developed to restore business operations within the required time frame following an interruption or failure to business process, as an outage could be just as fiscally devastating.
1.00	11.1.4	Business continuity planning framework	Whether there is a single framework of Business continuity plan. Whether this framework is maintained to ensure that all plans are consistent and identify priorities for testing and maintenance. Whether this identifies conditions for activation and individuals responsible for executing each component of the plan.
1.00	11.1.5	Testing, maintaining and re-assessing business continuity plan	Stays; Business continuity plans will need to be tested regularly to ensure that they are up to date and effective for the same reason as above.
1.00	12.1.1	Identification of applicable legislation	Stays; Business will still take place in the frameowrk of contracts and these will need to be reviewed to ensure all relevant statutory, regulatory and contractual requirements were explicitly defined and documented for each information system.
1.00	12.1.2	Intellectual property rights	Stays; again as there will still be laws and legal restrictions ensuring compliance with legal restrictions on use of material in respect of which there may be intellectual property rights such as copyright, design rights, trade marks, will need to be carried out to ensure that any coincidental similarities can be resolved.
1.00	12.1.3	Safeguarding of organisational records	Stays, it will still be important that records of the organization are protected from loss or accidental destruction.
1.00	12.1.4	Data protection and privacy of personal information	Stays; as mentioned there is a need for a management structure and controls to be in place to protect data from accidental loss or disclosure.
1.00	12.1.5	Prevention of misuse of information processing facility	Stays; the guideline of using information processing facilities for any non-business or unauthorised purpose, without management approval is treated as improper use of the facility is still applicable for a drawing of the boundries.
0.00	12.1.6	Regulation of cryptographic controls	Goes, the regulation of cryptographic control per the sector and national agreement will be a non issue, as nobody will be trying to crack encryption.
1.00	12.1.7	Collection of evidence	Stays, as there still may be business disagreements to settle the process involved in collecting the evidence will need to be in accordance with legal and industry best practise.
1.00	12.2.1	Compliance with security policy	Stays; it will still make sense to ensure the comprehensiveness of compliance with the defined Security policies.
1.00	12.2.2	Technical compliance checking	Stays; it will still make sense to ensure the comprehensiveness of compliance with security implementation standards as defined above.
1.00	12.3.1	System audit controls	Stays; Maintaining audit requirements and activities involving checks on operational systems will still need to be carefully planned and agreed to minimise the risk of disruptions to business processes.
1.00	12.3.2	Protection of system audit tools	Stays; Ensuring that system audit tools such as software or data files are protected to prevent any possible misuse or compromise will also ensure the integrity of the files against corruption, such as errors in distribution.
99.00