Access Control Proposal Essay

Access control: type of access control by which the operating system constrains the ability of a subject or initiator to access or generally perform some sort of operation on an object or target. In practice, a subject is usually a process or thread; objects are constructs such as files, directories, TCP/UDP ports, shared memory segments, IO devices etc. Subjects and objects each have a set of security attributes. Whenever a subject attempts to access an object, an authorization rule enforced by the operating system kernel examines these security attributes and decides whether the access can take place. Any operation by any subject on any object will be tested against the set of authorization rules (aka policy) to determine if the operation is allowed. A database management system, in its access control mechanism, can also apply mandatory access control; in this case, the objects are tables, views, procedures, etc. With mandatory access control, this security policy is centrally controlled by a secu rity policy administrator; users do not have the ability to override the policy and, for example, grant access to files that would otherwise be restricted. By contrast, discretionary access control (DAC), which also governs the ability of subjects to access objects, allows users the ability to make policy decisions and/or assign security attributes. (The traditional UNIX system of users, groups, and read-write-execute permissions is an example of DAC.) MAC-enabled systems allow policy administrators to implement organization-wide security policies. Unlike with DAC, users cannot override or modify this policy, either accidentally or intentionally. This allows security administrators to define a central policy that is guaranteed (in principle) to be enforced for all users. Historically and traditionally, MAC has been closely associated with multi-level secure (MLS) systems. The Trusted Computer System Evaluation Criteria[1] (TCSEC), the seminal work on the subject, defines MAC as â€Å"a means of restricting access to objects based on the sensitivity (as represented by a label) of the information contained  in the objects and the formal authorization (i.e., clearance) of subjects to access information of such sensitivity†. Early implementations of MAC such as Honeywell’s SCOMP, USAF SACDIN, NSA Blacker, and Boeing’s MLS LAN focused on MLS to protect military-oriented security classification levels with robust enforcement. Originally, the term MAC denoted that the access controls were not only guaranteed in principle, but in fact. Early security strategies enabled enforcement guarantees that were dependable in the face of national lab level attacks. Data classification awareness: For any IT initiative to succeed, particularly a security-centric one such as data classification, it needs to be understood and adopted by management and the employees using the system. Changing a staff’s data handling activities, particularly regarding sensitive data, will probably entail a change of culture across the organization. This type of movement requires sponsorship by senior management and its endorsement of the need to change current practices and ensure the necessary cooperation and accountability. The safest approach to this type of project is to begin with a pilot. Introducing substantial procedural changes all at once invariably creates frustration and confusion. I would pick one domain, such as HR or R&D, and conduct an information audit, incorporating interviews with the domain’s users about their business and regulatory requirements. The research will give you insight into whether the data is business or personal, and whether it is business-critical. This type of dialogue can fill in gaps in understanding between users and system designers, as well as ensure business and regulatory requirements are mapped appropriately to classification and storage requirements. Issues of quality and data duplication should also be covered during your audit. Categorizing and storing everything may seem an obvious approach, but data centers have notoriously high maintenance costs, and there are other hidden expenses; backup processes, archive retrieval and searches of unstructured and duplicated data all take longer to carry out, for example. Furthermore, too great a degree of granularity in classification levels can quickly become too complex and expensive. There are several dimensions by which data can be valued, including financial or  business, regulatory, legal and privacy. A useful exercise to help determine the value of data, and to which risks it is vulnerable, is to create a data flow diagram. The diagram shows how data flows through your organization and beyond so you can see how it is created, amended, stored, accessed and used. Don’t, however, just classify data based on the application that creates it, such as CRM or Accounts. This type of distinction may avoid many of the complexities of data classification, but it is too blunt an approach to achieve suitable levels of security and access. One consequence of data classification is the need for a tiered storage architecture, which will provide different levels of security within each type of storage, such as primary, backup, disaster recovery and archive — increasingly confidential and valuable data protected by increasingly robust security. The tiered architecture also reduces costs, with access to current data kept quick and efficient, and archived or compliance data moved to cheaper offline storage. Security controls Organizations need to protect their information assets and must decide the level of risk they are willing to accept when determining the cost of security controls. According to the National Institute of Standards and Technology (NIST), â€Å"Security should be appropriate and proportionate to the value of and degree of reliance on the computer system and to the severity, probability and extent of potential harm. Requirements for security will vary depending on the particular organization and computer system.†1 To provide a common body of knowledge and define terms for information security professionals, the International Information Systems Security Certification Consortium (ISC2) created 10 security domains. The following domains provide the foundation for security practices and principles in all industries, not just healthcare: Security management practices Access control systems and methodology Telecommunications and networking security Cryptography Security architecture and models Operations security Application and systems development security Physical security Business continuity and disaster recovery planning Laws, investigation, and ethics In order to maintain information confidentiality, integrity, and availability, it is important to control access to information. Access controls prevent unauthorized users from retrieving, using, or altering information. They are determined by an organization’s risks, threats, and vulnerabilities. Appropriate access controls are categorized in three ways: preventive, detective, or corrective. Preventive controls try to stop harmful events from occurring, while detective controls identify if a harmful event has occurred. Corrective controls are used after a harmful event to restore the system. Risk mitigation Assume/Accept: Acknowledge the existence of a particular risk, and make a deliberate decision to accept it without engaging in special efforts to control it. Approval of project or program leaders is required. Avoid: Adjust program requirements or constraints to eliminate or reduce the risk. This adjustment could be accommodated by a change in funding, schedule, or technical requirements. Control: Implement actions to minimize the impact or likelihood of the risk. Transfer: Reassign organizational accountability, responsibility, and authority to another stakeholder willing to accept the risk Watch/Monitor: Monitor the environment for changes that affect the nature and/or the impact of the risk Access control policy framework consisting of best practices for policies, standards, procedures, Guidelines to mitigate unauthorized access : IT application or program controls are fully automated (i.e., performed automatically by the systems) designed to ensure the complete and accurate processing of data, from input through output. These controls vary based on the business purpose of the specific application. These controls may also help ensure the privacy and security of data transmitted between applications. Categories of IT application controls may include: Completeness checks – controls that ensure all records were processed from initiation to completion. Validity checks – controls that ensure only valid data is input or processed. Identification – controls that ensure all users are uniquely and irrefutably identified. Authentication – controls that provide an authentication mechanism in the application system. Authorization – controls that ensure only approved business users have access to the application system. Input controls – controls that ensure data integrity fed from upstream sources into the application system. Forensic controls – control that ensure data is scientifically correct and mathematically correct based on inputs and outputs Specific application (transaction processing) control procedures that directly mitigate identified financial reporting risks. There are typically a few such controls within major applications in each financial process, such as accounts payable, payroll, general ledger, etc. The focus is on â€Å"key† controls (those that specifically address risks), not on the entire application. IT general controls that support the assertions that programs function as intended and that key financial reports are reliable, primarily change control and security controls; IT operations controls, which ensure that problems with processing are identified and corrected. Specific activities that may occur to support the assessment of the key controls above include: Understanding the organization’s internal control program and its financial reporting processes. Identifying the IT systems involved in the initiation, authorization, processing, summarization and reporting of financial data; Identifying the key controls that address specific financial risks; Designing and implementing controls designed to mitigate the identified risks and monitoring them for continued effectiveness; Documenting and testing IT controls; Ensuring that IT controls are updated and changed, as necessary, to correspond with changes in internal control or financial reporting processes; and Monitoring IT controls for effective operation over time. References : http://hokiepokie.org/docs/acl22003/security-policy.pdf Coe, Martin J. â€Å"Trust services: a better way to evaluate I.T. controls: fulfilling the requirements of section 404.† Journal of Accountancy 199.3 (2005): 69(7). Chan, Sally, and Stan Lepeak. â€Å"IT and Sarbanes-Oxley.† CMA Management 78.4 (2004): 33(4). P. A. Loscocco, S. D. Smalley, P. A. Muckelbauer, R. C. Taylor, S. J. Turner, and J. F. Farrell. The Inevitability of Failure: The Flawed Assumption of Security in Modern Computing Environments. In Proceedings of the 21st National Information Systems Security Conference, pages 303–314, Oct. 1998. Access Control Proposal Essay Proposal Statement Integrated Distributors Incorporated (IDI) will establish specific requirements for protecting information and information systems against unauthorised access. IDI will effectively communicate the need for information and information system access control. Purpose Information security is the protection of information against accidental or malicious disclosure, modification or destruction. Information is an important, valuable asset of IDI which must be managed with care. All information has a value to IDI. However, not all of this information has an equal value or requires the same level of protection. Access controls are put in place to protect information by controlling who has the rights to use different information resources and by guarding against unauthorised use. Formal procedures must control how access to information is granted and how such access is changed. This policy also mandates a standard for the creation of strong passwords, their protection and frequency of change. See more:  Perseverance essay Scope This policy applies to all IDI Stakeholders, Committees, Departments, Partners, Employees of IDI (including system support staff with access to privileged administrative passwords), contractual third parties and agents of the Council with any form of access to IDI’s information and information systems. Definition Access control rules and procedures are required to regulate who can access IDI information resources or systems and the associated access privileges. This policy applies at all times and should be adhered to whenever accessing IDI information in any format, and on any device. Risks On occasion business information may be disclosed or accessed prematurely, accidentally or unlawfully. Individuals or companies, without the correct authorisation and clearance may intentionally or accidentally gain unauthorised access to business information which may adversely affect day to day business. This policy is intended to mitigate that risk. Non-compliance with this policy could have a significant effect on the efficient operation of the Council and may result in financial loss and an inability to provide necessary services to our customers. Applying the Policy – Passwords / Choosing Passwords Passwords are the first line of defence for our ICT systems and together with the user ID help to establish that people are who they claim to be. A poorly chosen or misused password is a security risk and may impact upon the confidentiality, integrity or availability of our computers and systems. Weak and strong passwords A weak password is one which is easily discovered, or detected, by people who are not supposed to know it. Examples of weak passwords include words picked out of a dictionary, names of children and pets, car registration numbers and simple patterns of letters from a computer keyboard. A strong password is a password that is designed in such a way that it is unlikely to be detected by people who are not supposed to know it, and difficult to work out even with the help of a Protecting Passwords It is of utmost importance that the password remains protected at all times. Do not use the same password for systems inside and outside of work. Changing Passwords All user-level passwords must be changed at a maximum of every 90 days, or whenever a system prompts you to change it. Default passwords must also be changed immediately. If you become aware, or suspect, that your password has become known to someone else, you must change it immediately and report your concern to IDI Technical Support. Users must not reuse the same password within 20 password changes. System Administration Standards The password administration process for individual IDI systems is well-documented and available to designated individuals. All IDI IT systems will be configured to enforce the following: Authentication of individual users, not groups of users – i.e. no generic accounts. Protection with regards to the retrieval of passwords and security details. System access monitoring and logging – at a user level. Role management so that functions can be performed without sharing passwords. Password admin processes must be properly controlled, secure and auditable. User Access Management Formal user access control procedures must be documented, implemented and kept up to date for each application and information system to ensure authorised user access and to prevent unauthorised access. They must cover all stages of the lifecycle of user access, from the initial registration of new users to the final de-registration of users who no longer require access. These must be agreed by IDI. User access rights must be reviewed at regular intervals to ensure that the appropriate rights are still allocated. System administration accounts must only be provided to users that are required to perform system administration tasks. User Registration A request for access to IDI’s computer systems must first be submitted to the Information Services Helpdesk for approval. Applications for access must only be submitted if approval has been gained from Department Heads. When an employee leaves IDI, their access to computer systems and data must be suspended at the close of business on the employee’s last working day. It is the responsibility of the Department Head to request the suspension of the access rights via the Information Services Helpdesk. User Responsibilities It is a user’s responsibility to prevent their userID and password being used to gain unauthorised access to IDI systems. Network Access Control The use of modems on non- IDI owned PC’s connected to the IDI’s network can seriously compromise the security of the network. The normal operation of the network must not be interfered with. User Authentication for External Connections Where remote access to the IDI network is required, an application must be made via IT Helpdesk. Remote access to the network must be secured by two factor authentication. Supplier’s Remote Access to the Council Network Partner agencies or 3rd party suppliers must not be given details of how to access IDI ’s network without permission. All permissions and access methods must be controlled by IT Helpdesk. Operating System Access Control Access to operating systems is controlled by a secure login process. The access control defined in the User Access Management section and the Password section above must be applied. All access to operating systems is via a unique login id that will be audited and can be traced back to each individual user. The login id must not give any indication of the level of access that it provides to the system (e.g. administration rights). System administrators must have individual administrator accounts that will be logged and audited. The administrator account must not be used by individuals for normal day to day activities. Application and Information Access Access within software applications must be restricted using the security features built into the individual product. The IT Helpdesk is responsible for granting access to the information within the system. Policy Compliance If any user is found to have breached this policy, they may be subject to IDI’s disciplinary procedure. If a criminal offence is considered to have been committed further action may be taken to assist in the prosecution of the offender(s). If you do not understand the implications of this policy or how it may apply to you, seek advice from IT Helpdesk. Policy Governance The following table identifies who within [Council Name] is Accountable, Responsible, Informed or Consulted with regards to this policy. The following definitions apply: Responsible Head of Information Services, Head of Human Resources Accountable Director of Finance etc. Consulted Policy Department Informed All IDI Employees, All Temporary Staff, All Contractors. Review and Revision This policy will be reviewed as it is deemed appropriate, but no less frequently than every 12 months. Key Messages All users must use strong passwords. Passwords must be protected at all times and must be changed at least every 90 days. User access rights must be reviewed at regular intervals.  It is a user’s responsibility to prevent their userID and password being used to gain unauthorised access to IDI systems. Partner agencies or 3rd party suppliers must not be given details of how to access the IDI network without permission from IT Helpdesk. Partners or 3rd party suppliers must contact the IT Helpdesk before connecting to the IDI network. Access Control Proposal Essay 1 INTRODUCTION 1.1 Title of the project Access Control Proposal Project for IDI 1.2 Project schedule summary The project will be a multi-year phased approach to have all sites (except JV and SA) on the same hardware and software platforms. 1.3 Project deliverables †¢ Solutions to the issues that specifies location of IDI is facing †¢ Plans to implement corporate-wide information access methods to ensure confidentiality, integrity, and availability †¢ Assessment of strengths and weaknesses in current IDI systems †¢ Address remote user and Web site user’s secure access requirements †¢ Proposed budget for the project—Hardware only †¢ Prepare detailed network and configuration diagrams outlining the proposed change 1.4 Project Guides Course Project Access Control Proposal Guide Juniper Networks Campus LAN Reference Architecture 1.5 Project Members David Crenshaw, IT Architect and IT Security Specialist Members of the IT Staff 1.6 Purpose A proposal for improving IDI’s computer network infrastructure is the purpose for this proposal. This project is intended to be used by IDI’s information security team to developing a plan to improve IDI’s computer network infrastructure at multiple locations. 1.7 Goals and Objectives Objective 1 To assess the aging infrastructure and then develop a multi-year phased approach to have all sites (except for JV and SA) on the same hardware and software platforms. Objective 2 The core infrastructure (switches, routers, firewalls, servers and etc.) must capable of withstanding 10 – 15% growth every year for the next seven years with a three-to-four year phased technology refresh cycle. Objective 3 Solutions to the issues that the specifies location of IDI is facing Objective 4 Assessment of strengths and weaknesses in current IDI systems Objective 5 Address remote user and Web site user’s secure access requirements Objective 6 Prepare detailed network and configuration diagrams outlining the proposed change Objective 7 Prepare a 5 to 10 minute PowerPoint assisted presentation on important access control infrastructure, and management aspects from each location. Objective 8 A comprehensive network design that will incorporate all submitted requirements and allow for projected growth. Objective 9 Final testing of all installed hardware, software, and network connectivity. Objective 10 Initialization of the entire network and any last minute configuration adjustments to have the network up and operating within all specified ranges. 2 Current Environment 2.1 Overall: There are a variety of servers, switches, routers, and internal hardware firewalls. Each of the organization’s locations is operating with different information technologies and infrastructure—IT systems, applications, and databases. Various levels of IT security and access management have been implemented and embedded within their respective locations. The information technology infrastructure is old and many locations are running on outdated hardware and software. Also, the infrastructure is out dated in terms of  patches and upgrades which greatly increase the risk to the network in terms of confidentiality, integrity, and availability. 2.2 Data Center: Logisuite 4.2.2 has not been upgraded in almost 10 years. Also, numerous modifications have been made to the core engine and the license agreement has expired. Progressive upgrading to the current version will be required. As a result, renewing this product will be extremely cost and time-prohibitive. RouteSim is a destination delivery program used to simulate routes, costs, and profits. It is not integrated into Logisuite or Oracle financials to take advantage of the databases for real-time currency evaluation and profit or loss projections. IDI’s office automation hardware and software has not been standardized. Managers have too much liberty to buy what they want according to personal preferences. Other software problems include early versions of MS Office 5, WordPerfect 7.0, and PC-Write that are not compatible. Telecommunications has not been since the company moved its current headquarters 15 years ago. This has left many of the new features for telecommunications lacking and not integrated with the customer service database to improve call management efficiency. The generic system was acquired from a service provider who is now out of business. Policies for personal devices are being ignored by many of the executives who have local administrators install the clients on their unsupported, non-standard personal laptop computers and workstations that interface with the internet. The original WAN was designed in the early 2000’s and has not been upgraded. During peak periods, usually between September and March, the capacity is insufficient for the organization resulting in lost internet customers which  further reduces growth and revenue. Telecommunications works through a limited Mitel SX-2000 private automatic branch exchange (PABX) that only provides voice mail and call forwarding. 2.3 Warsaw, Poland This is the largest office based on number of employees, strategically located to assist IDI for major growth in the Middle East and Asia, and the home portal for expansion and geographical client development, yet there is insufficient computing power to stay afloat on a day-to-day basis. The primary freight forwarding application is almost 10 years old and does not interface with the McCormack dodge accounting and finance system There are 6 Web servers (4 are primary and 2 fail during clustered load balancing) The cafeteria sponsors a public wireless network running WPA (Wi-Fi Protected Access) with no password protection. Telecommunications is an 8 year old Siemens Saturn series PBX, some of whose features have become faulty. The desktop phones have not been replaced or upgraded during this time. There is a lack of separation of duties between the network operations and the accounts receivable department and there is evidence of nepotism and embezzlement. 2.3 Sao Paulo, Brazil Vendors are unwilling to sign a service agreements.