3

When creating a Security Policy such as Password Policy, what are some of the typical assets that need to be protected?


And how does this affect, employees, contractors, vendors, suppliers, and representatives who access the organization-provided or organization-supported applications, programs, networks, systems, and devices.


A Bank Corporation which has a large staff, different data centers, intranet, and web-based access.

Information:

  • Data about customers.
  • Payment transactions.
  • Information about employees.
  • Logs.

What other assets or information can one include, which needs to be protected. Additionally, a Password Policy of some type must be designed, so that staff, can access sensitive information about bank customers which have their accounts there. Meaning, the digital environment of a BANK CORPORATION used by employees.

  • Administrators
  • CEO
  • Employees
  • Customers
17
  • 4
    In my opinion the question is lacking focus. There is no generic password policy which fits all cases and in many cases passwords are either non sufficient or impact usability too much. And assets to protect are in general data, systems and processes but more details and how much and what kind of protection is needed depend on the specifics of the environment. Feb 8 '20 at 17:32
  • 2
    The changed title does not make the question itself more focused. Even worse, you now have a question in the title and a different one in the body. Feb 8 '20 at 18:11
  • 2
    It is still very broad. Given that you want to learn you should maybe start smaller: Instead of asking about a range of unspecific use cases ("typical assets") and a range of people affected ask about a very specific use case which is actually relevant for you and where you can provide enough details about this use case. Then you can ask what kind of password policy would make sense in this case and why. From this you can get an idea what the aspects relevant for a password policy are. Feb 8 '20 at 19:08
  • 2
    While a bit more specific this is still a pretty broad question. You expecting in the answer not only a password policy with explanation but a list of all assets which need to be protected in a bank (on top of the ones you've mentioned). And there might actually be multiple password policies depending on the specific kind of protection needed. I think you should go much much smaller and have a use case which is actually relevant for you personally and where you know the environment and assets and what kind of protection they need in detail. Feb 8 '20 at 20:58
  • 3
    Again, if you want to learn about designing a password policy start with a use case which is actually familiar to you. If you want to know what assets need to be protected in a bank focus on this instead (but I doubt this is really on-topic here). Don't mix both aspects into a single question since it gets too broad then. Feb 8 '20 at 21:34
1
+50

Password Policies

A password policy cannot be created in a vacuum, it must be derived from the Security Policy & Process of the Organization. Usually, this is called the ISMS, or Information Security Management System. In the general case, it will consist of a variety of policy documents addressing different aspects of information security.

For Banking and Payments, an ISMS will direct its Business Units to derive best practices from at least the following standards and regulatory artifacts:

  • PCI SSC – Payment Card Industry Security Standards Council
  • SOX – Sarbanes-Oxley Act
  • GLBA – Gramm-Leach-Bliley Act
  • … and potentially others.

Per PCI, SOX and GLBA requirements, your password needs will comply with these requirements:

PCI DSS

  • 2.1 – Never use vendor-supplied defaults
  • 2.3 – Encrypt all non-console administrative access using strong cryptography
  • 3.6.6 – If manual clear-text cryptographic key-management operations are used, these operations must be managed using split knowledge and dual control.
  • 6.3.1 – Remove development, test and/or custom application accounts, user IDs, and passwords before applications become active or are released to customers.
  • See Requirement 8: Identify and authenticate access to system components

SOX

Sarbanes-Oxley experts and auditors recommend that to meet the minimum for compliance, passwords should:

  • Be at least eight characters long;
  • Include a combination of letters and numbers;
  • Not contain personal information.

GLBA

Section 501 of the GLBA, “Protection of Nonpublic Personal Information,” requires financial institutions to establish appropriate standards related to the administrative, technical, and physical safeguards of customer records and information. The scope of these safeguards is defined in the GLBA Data Protection Rule, which states that financial institutions must:

  • Ensure the security and confidentiality of customer data
  • Protect against any reasonably anticipated threats or hazards to the security or integrity of such data
  • Protect against unauthorized access to, or use of, such data that would result in substantial harm or inconvenience to any customer.

Security Policies

When creating any kind of Security Policy, avoid the temptation to first consider assets, such as information systems consisting of infrastructure, applications, and operating systems. Instead, focus on the sensitive information that requires protection. A Security Policy is a high-level statement (plan or framework) addressing security requirements and objectives. It may address an entire organization or be specific to an issue or system.

A security policy is a type of governance in that it expresses the security framework established by management. It is the primary method by which an organization sets expectations for a variety of topics.

  • The audience for the policy consists of architects, designers, implementers, installers, maintainers, and users of the Information the Organization needs to protect.
  • Policies can be written to affect hardware, software, access, people, connections, networks, telecommunications, enforcement, and so forth.
  • A good Security Policy cannot be drafted without a comprehensive understanding of the security standards that must be achieved.

Security Standards

While a Security Standard may be an internally developed, it is usually an external document authored by a regulatory organization (e.g., PCI SSC), or an organization tasked with developing best practices (e.g., NIST, ISO, ISACA).

  • A Security Standard is an enumeration of actions or rules that must be performed or followed to implement a best practice. E.g., NIST SP-800-53, ISO 27001, COBIT

Process

  • A Security Process defines a set of activities or related tasks that when combined, produce the desired result.

Procedures

  • Procedures are step-by-step instructions to perform various tasks in accordance with established Policy, Process,

Guidelines

  • Guidelines provide advice regarding how to achieve a goal of a Security Policy, or Process. They are a communication tool used to provide suggestions, they do not provide rules.

Developing an Information Security Policy

Data Identification and Scope

  • Identify sensitive information that must be protected;
  • Identify every location where sensitive information is scored;
  • Develop data classifications and tag data;
  • Determine in-scope information systems and out-of-scope information systems, tagging information systems appropriately;
  • Determine the approved ways in which data may be accessed.

Develop a Risk Management Framework

A Risk management framework helps you understand the risks associated with your information and how to manage those risks.

This is a key process to developing a password policy.

  • Establishing a risk assessment framework
  • Identify risks
  • Analyze risks
  • Evaluate risks
  • Select risk management options

Create the Risk Treatment Plan

This involves creating and managing security controls to mitigate and remediate risks.

Putting it together

Once you understand the data that must be protected, and the systems that process that data, the risks to which you are most commonly exposed, you can then begin developing requirements for Information Systems relevant to:

  • Regulatory requirements;
  • Data classification;
  • Best Practices;
  • User Experience & Acceptance
3
  • 2
    Good for CISSP revision :)
    – elsadek
    Feb 11 '20 at 8:20
  • 1
    Thanks for this. This was really helpful. Thank you again. ;-)
    – John Smith
    Feb 12 '20 at 14:22
  • 1
    You're welcome. Happy travels!
    – W1T3H4T
    Feb 13 '20 at 1:25
1

Let me try to answer this question.

In general, it is the role of the business owners to have up to date inventory of all assets, to decide on critical assets and to prioritize the importance of before any further business impact analysis and action related to security (confidentiality, integrity, accessibility) happens.

One could classify assets and data related to any organization's security as follows:

1) assets the organization owns and has control over:

  • physical security, physical access control systems, access to media including electricity, water, gas, fiber, any cabling, building structure
  • on-premise infrastructure including on-premise IT systems, applications, and networks
  • IoT devices (ATMs, routers, switches, printers, displays, PoS kiosks, smart TV displays, UPS)
  • corporate laptops, tablets, smartphones
  • WiFi and LAN networks,
  • VPN access,
  • virtualization (VMs, virtual firewalls, containers)
  • Mobile banking applications (including access to source code, access to platforms and shops)
  • firewalls
  • backup and archiving solutions
  • public and intranet websites
  • content management systems
  • document management systems
  • any process automation solutions
  • business intelligence, business warehouse solutions
  • operational data databases
  • legacy systems, obsolete systems
  • data on external media (USB sticks, memory cards, external drives, CD/DVD storage)
  • confidential printouts, including mail
  • smart cards, hardware security tokens
  • biometric data repository
  • Software Development Lifecycle-related (CI/CD applications, source code versioning repositories, development access keys)
  • testing environments
  • experimental/sandbox systems
  • Data Leakage Prevention systems
  • logging and auditing systems
  • Identity and Access Management systems
  • Governance, Risk and Control systems
  • Fraud Management systems
  • call-center systems
  • CRM systems
  • PII data: employee data, customer data, vendor data (master data, voice/audio recording)
  • IP: intellectual property, strategic analysis, contracts, and procurement
  • software licensing,
  • software patching,
  • Password Management software

2) items the organization interacts with but has limited control over:

  • employees, externals and on-site contractors,
  • cloud systems (IaaS, PaaS, SaaS, FaaS),
  • third party systems and their maintenance and security roadmaps,
  • third party software and their maintenance and security roadmaps,
  • BIOS
  • OS source code
  • interface/middleware/API access for customers, vendors, and government,
  • Bring-Your-Own-Device (smartphones, tablets, laptops)
  • vendors and their IT systems
  • third party load balancers, cache
  • third party OATH, identification and authentication providers

3) items the organization has no control over:

  • customers and their IT systems, government (regulatory, compliance, legal, law enforcement) systems, that require and collect data via connectors/APIs/periodic data transfers,
  • automated internet crawlers, data collectors and bots
  • random visitors
  • hardware-level security ( CPU, memory, trusted platform module, data ports)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.