Security Policies and Regulations
The course is part of this learning path
This course is one of four courses covering Domain 1 of the CSSLP. This course explores the topic of security policies and regulations.
- Obtain a general understanding of security policies, regulations, and compliance
- Understand the legal and privacy issues that these regulations aim to address
- Learn about a variety of security frameworks and standards
- Learn about trusted computed principles and how they underpin security frameworks
- Understand the security implications of acquiring software
This course is designed for those looking to take the Certified Secure Software Lifecycle Professional (CSSLP) certification, or for anyone interested in the topics it covers.
Any experience relating to information security would be advantageous, but not essential. All topics discussed are thoroughly explained and presented in a way allowing the information to be absorbed by everyone, regardless of experience within the security field.
If you have thoughts or suggestions for this course, please contact Cloud Academy at email@example.com.
Section three, security policies and regulations. In this particular section, we're going to discuss the what and the why of security. Covering the topics you see there on the introductory slide. Now, contrary to what one may think it to be, a security policy is more than merely a written document. It is the instrument by which digital assets that require protection can be identified. It specifies at a high level, the what that needs to be protected and the possible repercussions of non-compliance.
In addition to defining the assets that the organization deems as valuable, security policies identify the organization's goals, objectives, and communicate management's goals and objectives for the organization. The security policy provides the framework and the point of reference that can be used to measure an organization's security posture. The gaps that are identified when being measured against a security policy, a consistent point of reference, and can be used to determine effective executive strategy and serve as the basis for many decisions.
Additionally, security policies ensure non-repudiation because those who do not follow the security policy can be personally held accountable for their lack of compliance, their behaviors and actions. Security policies can be used to provide guidance to design secure software by addressing the confidentiality, integrity, and availability, and the other aspects essential to secure software.
Security policies can also define the functions and scope of the security team, document incident response, and enforcement mechanisms and provide for exception handling, rewards and discipline. So with regard to regulations and compliance, we find that many of the activities within an enterprise of almost any description will be caused by a variety of regulations and compliance requirements. Failing to satisfy these, and they should be regarded as mandatory elements, whether they serve from industry sources or from legal and regulatory sources, failing to follow these can result in penalties, losses of opportunities, and reputational damage.
Knowing that vital software is to a company's operation essential, security and privacy staff must fully appreciate how it is impacted and what the consequences of this non-compliance or non-performance will be. Now one of the things that must be taken into account is the scope of the security policies. These can be either organizational or functional. Now organizational policy tends to be universally applicable and to all who are part of the organization must comply with it. Unlike a functional policy which is limited to a specific functional unit or to a specific issue. For example, an organizational policy may be with regard to remote access, and that is applicable to all employees and non-employees such as third parties and contractors that require remote access into the organizational network.
An example of a functional security policy is the data confidentiality policy, which specifies the functional units that are allowed to view sensitive or personal information. In some cases, these can even define the rights personnel have within this functional unit. For example, not all members of the human resources team are allowed to view the payroll data of executives. So it may be a simple comprehensive document or the policy itself may be comprised of many specific informational security policy elements.
Mr. Leo has been in Information System for 38 years, and an Information Security professional for over 36 years. He has worked internationally as a Systems Analyst/Engineer, and as a Security and Privacy Consultant. His past employers include IBM, St. Luke’s Episcopal Hospital, Computer Sciences Corporation, and Rockwell International. A NASA contractor for 22 years, from 1998 to 2002 he was Director of Security Engineering and Chief Security Architect for Mission Control at the Johnson Space Center. From 2002 to 2006 Mr. Leo was the Director of Information Systems, and Chief Information Security Officer for the Managed Care Division of the University of Texas Medical Branch in Galveston, Texas.
Upon attaining his CISSP license in 1997, Mr. Leo joined ISC2 (a professional role) as Chairman of the Curriculum Development Committee, and served in this role until 2004. During this time, he formulated and directed the effort that produced what became and remains the standard curriculum used to train CISSP candidates worldwide. He has maintained his professional standards as a professional educator and has since trained and certified nearly 8500 CISSP candidates since 1998, and nearly 2500 in HIPAA compliance certification since 2004. Mr. leo is an ISC2 Certified Instructor.