SecureState Blog

Read SecureState's award winning blog.

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.