ISC Categories



Information Security Controls

IA | Basic Authentication
This section covers the main aspects of authentication into the different components of the solution, the process to grant and revoke access, and the underlying technology and protocols used to support identity management. A typical assessment will check if:

  • Will the solution be using local accounts?
  • Will there be any usage of shared accounts?
  • Will it be integrated with current directory services such as AD?
  • Will there be any RBAC (Role-Based Access Control) in place?
  • Will it be integrated with an authentication scheme like SSO?
  • Will there be a robust and defined JML process in place?
  • Will it be defined who will approve the creation of new users?
  • What will be the policy for account lockout and password expiration?
  • Will the solution send user access logs to the centralized logging solution?

IA | Strong Authentication
Strong Authentication looks over those enhanced controls that can be applied to a solution such as the usage of multiple-factor authentication, how public key infrastructure is integrated into the solution, or how advanced access systems such as Privileged Access Management are levered. A typical assessment will check if:

  • Will the components of the application itself use MFA?
  • Will the solution use certificate for access instead of passwords?
  • Will access to the components be integrated with the enterprise PAM solution?
  • Will there be any integration with the current enterprise PKI infrastructure?
  • Will there be any hardware tokens in place?

IA | Account Auditing
This section has as a focus all aspects of managing the lifecycle of account provisioning. In particular, user access review, system account review and roles review. It is a critical aspect of every solution to ensure that any account and access granted are reviewed periodically to ensure whether the access is still needed, and to verify no additional accounts where added without permission. A typical assessment will check if:

  • What will be the process to review existing user accounts on a periodical basis?
  • What will be the overall procedure to review privileges, roles and access?
  • Where will the records of these approvals be stored for future audits?

IA | Remote Access
In today’s world, there is a growing reliance in accessing systems hosted remotely in the cloud even from the main office, for personnel working remotely from their homes, or simply for users to access a specific system from anywhere in the world. Ensuring there is a good understanding behind this access is a critical step to protect the organization. A typical assessment will check if:

  • What will be the process for remote access for users, privileged users and third-parties?
  • What technology and protocols will be used to allow remote access? (e.g. vpns, vdi, citrix)
  • Will it be integrated with the enterprise directory service, or will it use a different system?
  • Is there a good understanding of the components that will be used to provide this service?

SA | System Administration
This category ensures a review through every security measure in place to manage the assets of the solution from a privileged administration point of view, which is typically referred to as the backend. It is of the most importance to safeguard and control the access from privileged users, ensuring there are security controls in place so only those with access can manage the devices. A typical assessment will check if:

  • How will assets of the solution be managed from an administration point of view?
  • Will it be using a management VLAN?
  • Is there a centralized Jumpbox infrastructure to access devices?
  • Will it be using a PAM solution?
  • How will password be managed? (e.g. centralized solution, password vault)
  • What will be the process for account lockout and password expiration?
  • Will it use PKI/Certificates?
  • Will it use MFA?
  • How will endpoints be protected?
  • Will access logs be sent to a centralized logging solution?

SA | Network Security
This section covers the main security design aspects of where the assets are deployed. There must be a thorough understanding on the network topology, the network devices protecting them, the layered defense architecture and the technologies used in the organization to prevent threats. A typical assessment will check if:

  • Will the components of the solution be protected in a network zone behind firewalls?
  • Will ports be restricted to the bare minimum?
  • Will there be any IPS/IDS in place to protect traffic coming into the system?
  • Will there be a web proxy to filter traffic going out of the system?
  • Will the solution be in a network segmented/segregated zone?
  • If there is a VPN connecting to a third-party, how will be secured?
  • Will there be any NAC controls in place?

SA | Data in Transit
A good understanding on how data flows is a key aspect to being able to secure it. Described as data in motion in some cases, this section deals with how data moves from one point to another, passing through trusted or untrusted networks. A typical assessment will check if:

  • Is there a good understanding of the data flow?
  • If there is web access, what protocols will be in use? (e.g. http, https)
  • How will data be transferred between components and dependencies? (e.g. sftp, ftp)
  • Will data be moving through unsecured networks? If it is, what encryption will it use?
  • How will data be replicated between servers across datacenters and/or cloud hosting?

SA | Data at Rest
This section covers how data is secure when is considered inactive, or in other words, where data is stored which could be in a database, server, shared drive, NAS, or even removable devices. A typical assessment will check if:

  • Where will be the data be hosted?
  • Will there be any encryption in servers, in cloud, in databases?
  • Will anything be stored in endpoints?
  • Is it clear who will have access to stored data?
  • Will it be restricted to only those who needed it?

SA | Application Security
This category is focused on web-based applications and software development lifecycle. It refers to the controls around software, coding guidelines and standards, audit mechanisms and the threats and vulnerabilities inherent to these systems. It is critical to understand this process to ensure secure software. One of the main goals is to minimize risks against OWASP Top-10 (Open Web Application Security Project) such as injection vulnerabilities, broken authentication, data exposure, cross-site-scripting, usage of components with known vulnerabilities to name a few. A typical assessment will check if:

  • What are the coding practices and standards focused on security?
  • Are any automated security assessment tools being used? (e.g. Amazon Inspector)
  • Will the final product go through any sort of penetration testing?
  • Will inputs be sanitized at the client and server side?
  • What encryption and hashing algorithms will be used?
  • Will directory listing be blocked?
  • Will sensitive data be stored in cookies?
  • Will TLS be used instead of SSL?
  • What will be the password policy?
  • Will web server and OS version information be hidden?

SA | Mobile Systems
Mobile systems such as phones, tablets and POS are just as prone to vulnerabilities as other computing systems. As these devices are small and portable by nature, and are either being carried by users or located in very visible areas, they can be stolen more easily than other assets. Ensuring these devices are secure and do not contain unrestricted access or sensitive information is critical to ensure the security of the organization. A typical assessment will check if:

  • What will be the process for account management?
  • Will it use MFA to access critical services?
  • What will be the password and PIN policies?
  • Will it be integrated with the enterprise MDM (Mobile Device Management)?
  • Will it have any remote wipe capabilities if necessary?
  • Will users be able to install new applications and/or change core system settings?
  • Will devices be encrypted by default?
  • How will remote access be used? (e.g. VPN, Citrix)
  • What will be the process for patching procedures?
  • What will be the session lifetime, when will it force to re-authenticate?
  • How will these devices be integrated into the asset management process?

SA | Security Principles
Any solution being assessed must ensure that security principles are being followed. One of the most known is the CIA Triad which looks at three foundational security principles: Confidentiality, Integrity and Availability. In addition, other specific security principles should be checked if they are relevant to the solution. A typical assessment will check if these principles are being followed:

  • Minimizing attack surface area (restrict functions that users are allowed to access).
  • Establish secure defaults (steps must be taken to obtain higher privileges).
  • Least privilege (assign the minimum set of privileges required to perform a specific task).
  • Need to know (grant access only to the data need to users to perform their job).
  • Defense in depth (multiple security controls that approach risks in different ways).
  • Fail securely (failures should not grant access, nor give sensitive information).
  • Separation of duties (prevent individuals from acting fraudulently by separating duties).
  • Avoid security by obscurity (security controls must be in place instead of hiding functions).
  • Keep security simple (avoid the use of very sophisticated mechanisms or architecture).
  • Domain separation (place devices with similar security attributes together, permit communications to other domains through secure and controlled channels).
  • Layering (structure a solution into different levels of abstraction with different permissions).

SC | Baselines
Baselines are derived from policies and standards to meet specific implementation and compliance requirements. These baselines will ensure the minimum set of security controls are being applied to assets. A typical assessment will check if:

  • Will the solution be using approved and hardened baseline AMI Images?
  • Who will be responsible to update them?
  • What will be the process to request any change to the baseline?
  • Will the solution use CIS Benchmarks?
  • Will the solution use Microsoft Security Compliance ToolKit?
  • Will the solution use Cisco Validated Design Program?

SC | Change Control
This category refers to the process that ensures changes to the system are introduced in a secure, controlled and coordinated manner. One of the main goals is to minimize disruption to services and ensure changes are approved and deployed following the guidelines of the organization. A typical assessment will check if:

  • What will be the process to perform changes?
  • Who will review and approve the changes?
  • Where will be these changes recorded?

SC | Patching Procedures
This category refers to the overall process to ensure system patches to fix bugs, flaws or vulnerabilities are following the guidelines established by the organization, which could be applied manually or automatically. A typical assessment will check if:

  • What will be the practices to patch the backend?
  • Will the solution be using any automatic patching tools? (e.g. WSUS or SCCM)
  • How will announced vendor vulnerabilities be handled?
  • If there is a third-party involved, will the organization receive notifications of their work?

SC | Vulnerability Management
Vulnerability Management refers to the process of identifying, evaluation and reporting security vulnerabilities associated to specific systems, applications and environments. This category ensures the solution being assessed is complying with the overall process defined by the organization. A typical assessment will check if:

  • Will it be integrated with the current vulnerability management platform?
  • What will be the process when a vulnerability is detected by the security team?
  • Is the solution using hardware and software supported by the vendor and/or manufacturer?