Firewall Rules Review – Best Practices

Firewall Rules Review – Best Practices

  • Firewall Rule Change Control Form should be used for each firewall rule addition or modification.
  • Details to be captured:
  • Requesting Department
  • Requestor from the Requesting Department
  • Approver from the Requesting Department
  • Source IP, Hostnames and Ownership Information
  • Destination IP, Hostnames and Ownership Information
  • Destination Port that needs to be Opened in the Firewall
  • Business Justification for the Firewall Rule
  • The width of the rule (source, destination and ports being allowed) should be as minimum as possible.
  • Duration of Applicability (As minimum as possible)
  • Approver from Reviewing Department
  • Unique ID to identify the Firewall Rule
  • Date of Request of Firewall Rule
  • Date of Final Approval of Firewall Rule
  • Quarterly review should be performed on firewall rules.  Expired rules should be removed after confirmation from the Requestor Department Manager.
  • Annual review should be performed on non-expiring firewall rules.  Rules should be removed unless approved by the Requestor Department Manager.


Firewall Rules Review – Best Practices

Mobile Device Security

Mobile Device Security

  • Company Confidential Data should be stored in an encrypted container.
  • The mobile device should only retain minimal data required to support business processes and functionalities.  Data should be transferred to the server for permanent storage using secure protocols.
  • Application cache should be purged once the application exits or after a fixed period of inactivity.
  • Application backgrounding should result in the presentation of a screen which do not display any sensitive information.
  • A Mobile Device Management (MDM) solution such as Blackberry GOOD should be used to manage applications deployed to company staff.
  • MDM should support remote wipe of the application data container and processes and policies for remote wipe should be set.
  • Company deployed applications should be password protected based on the company’s Password Policy.
  • Application should be locked after a specific period of inactivity.
  • Application data container should be wiped off after a certain number of successive unsuccessful login attempts.
  • Use of company applications should be supported by the Company’s Mobile Device Security Policy.  Consent of the users to the policy should be captured and recorded.
Mobile Device Security

Cost of End-To-End Encryption

Cost of End-To-End Encryption (Lack of Intrusion Detection / Prevention in Encrypted Traffic)

End-to-end encryption has its cost.  Intrusion Detection and Prevention Systems (IDS and IPS)  are unable to analyze encrypted traffic and attack vectors may get through the iDS / IPS if the traffic is in an encrypted format.  Encryption should be maintained as close to the Destination Server as possible.  Once the traffic is in a secure site, the traffic can be decrypted for analysis by Firewalls, IDS and IPS devices before they reach their Destination Servers.

IDS and IPS devices by themselves are incapable of decrypting and re-encrypting traffic.  Until this technology is developed, there is a risk of data sniffing at the last mile where the IDS / IPS is setup.  But this risk could be significantly lower than the risk of malicious traffic reaching your destination servers.  The risk of data sniffing could be further reduced by securing the DC, segregating the last mile communication into separate VLAN and turning off port mirroring for the VLANs concerned.


Cost of End-To-End Encryption

Password Management at the Application Server

External Module Password Management at the Application Server

  • Do not hardcode secrets (example: passwords, private keys, etc) in source code.
  • Keep secrets in a separate centralized configuration file, that can be referenced by different application modules.  The configuration file should have much restrictive access permissions.  It should not be added to Version Control Programs.  It should not be in the downloadable path of any web application.
  • Keep the configuration file contents encrypted using a separate application password.  The application can decrypt the file on-the-fly to retrieve the secret information and leave the file encrypted after use.
  • If the configuration file contents cannot be encrypted, at least store them in encoded format (Base 16, Base 32, Base 64, etc), so that they cannot be easily memorized.
  • Access to the configuration file should also be logged by the Operating System into a Central log server.


Password Management at the Application Server

Cryptographic Key Management

Cryptographic Key Management

What are the common cryptographic keys in use?

  • Asymmetric keys for PKI
  • Asymmetric keys for SSL tunnel creation
  • Symmetric keys used for encryption of data

How does the Web Server / Load Balancer create the SSL session key for encrypting each session with the Client browser?

The secret session key for an SSL session is derived from a pre-master secret created by the client browser using its OS’s inherent random number generator.  The browser encrypts the pre-master secret with the server’s public key and sent to the server.  The server uses the pre-master secret to derive the secret key for further onward encryption of the data transferred in the SSL session.  The secret key is stored in cache only and is purged after the session expires.

How does proprietary Database, Fileserver, Data Backup Solution Server encrypt data?

Case-in-Point: Oracle Transparent Database Encryption (TDE).

  • Uses built-in Key Management solution.

Case-in-Point: EMC Data Domain which can be used as a Data Backup and Recovery Solution.  It provides the below options for Data-At-Rest encryption:

  • Static Key managed internally.
  • Internal Key Management for periodic Key Rotation.
  • External Key Management is allowed through RSA Data Protection Manager (DPM) server.

Case-in-Point: EMC VNX series of Storage Devices which could be used as a File Server.

  • Includes a Keystore, which is an embedded and independently encrypted container which holds all the Data-at-Rest Encryption keys on the data arrays.  The data array has an internal key manager called VNX Key Manager.  External key managers are not supported.

Key Management Solution (KMS)

A key management solution (KMS) is an integrated approach for generating, distributing and managing cryptographic keys for devices and applications. Compared to the term key management, a KMS is tailored to specific use-cases such as secure software update or machine-to-machine communication. In an holistic approach, it covers all aspects of security – from the secure generation of keys over the secure exchange of keys up to secure key handling and storage on the client. Thus, a KMS includes the backend functionality for key generation, distribution, and replacement as well as the client functionality for injecting keys, storing and managing keys on devices. With the Internet of Things, KMS becomes a crucial part for the security of connected devices.

There are many proprietary KMS.  Example: RSA Data Protection Manager, Amazon Web Service KMS, HP Enterprise Security Key Manager, Oracle Key Manager, Safenet Enterprise Key Management.

Use of Hardware Security Module (HSM) for the protection of Cryptographic Keys

A hardware security module (HSM) is a physical computing device that safeguards and manages digital keys for strong authentication and provides cryptoprocessing. These modules traditionally come in the form of a plug-in card or an external device that attaches directly to a computer or network server.  HSMs may possess controls that provide tamper evidence such as logging and alerting and tamper resistance such as deleting keys upon tamper detection. Each module contains one or more secure cryptoprocessor chips to prevent tampering and bus probing.  Many HSM systems have means to securely backup the keys they handle either in a wrapped form via the computer’s operating system or externally using a smartcard or some other security token.  Because HSMs are often part of a mission-critical infrastructure such as a public key infrastructure or online banking application, HSMs can typically be clustered for high availability. Some HSMs feature dual power supplies and field replaceable components such as cooling fans to conform to the high-availability requirements of data center environments and to enable business continuity.

A hardware security module can be employed in any application that uses digital keys. Typically the keys must be of high-value – meaning there would be a significant, negative impact to the owner of the key if it were compromised.  The functions of an HSM are:

  • onboard secure cryptographic key generation
  • onboard secure cryptographic key storage and management
  • use of cryptographic and sensitive data material
  • offloading application servers for complete asymmetric and symmetric cryptography

HSM are also deployed to manage Transparent Data Encryption keys for databases.  HSMs provide both logical and physical protection of these materials, including cryptographic keys, from non-authorized use and potential adversaries.  The cryptographic material handled by most HSMs are asymmetric key pairs (and certificates) used in public-key cryptography.  Some HSMs can also handle symmetric keys and other arbitrary data.

Use of HSM for End-to-End Encryption of User Password

HSM mainly provides end-to-end encryption of the User Password – [i] Browser to HSM Flow; and [ii] HSM to Application Database Flow.  This is  through secure generation of Asymmetric key pairs on demand (for end-to-end encryption of User Password from Browser to HSM) and secure management of a Symmetric key for storage of User Password in an encrypted format in an external Database (for end-to-end encryption of User Password from HSM to Application Database).  The User Password remains in an unencrypted form only at the User’s Browser.  The User Password remains in a cleartext-hashed format at both the User’s Browser and the HSM, but nowhere else.

General HSM Security Features

  • Provide strong physical and logical protection of cryptographic keys – Asymmetric key pairs and Symmetric keys.
  • Asymmetric key pairs are created to handle User Authentication.  Public key created will be passed to the application server who passes it to the application client.  The application client encrypts the user password hash with the public key.  The user password hash will be retrieved by the HSM by decrypting using the private key.  The user password hash will then be encrypted with a secret key and passed to the application server for storage in its LDAP or Database.  Both the values – user password hash encrypted with public key and user password hash encrypted with secret key – will be passed back to the UAS for matching and authentication of a User.
  • Only allow connectivity from pre-defined servers using IP restriction.
  • Configuration of HSM only allowed by physically visiting the HSM at the Datacenter with the physical Keys and User ID/Password credentials.
  • Installation and configuration of HSM driver is needed at the connecting server before connection establishment.
  • Support for High-Availability clustering supported by configuration in the HSM driver.

PKI environment (CA HSMs)

In PKI environments, the HSMs may be used by certification authorities (CAs) and registration authorities (RAs) to generate, store, and handle key pairs. In these cases, there are some fundamental features a device must have, namely:

  • Logical and physical high level protection
  • Multi-part user authorization schema
  • Full audit and log traces
  • Secure key backup

On the other hand, device performance in a PKI environment is generally less important, in both online and offline operations, as Registration Authority procedures represent the performance bottleneck of the Infrastructure.

Card payment system HSMs (bank HSMs)

Limited-feature HSMs are used in card processing systems. These systems are usually less complex than CA HSMs and normally do not feature a standard API. These devices can be grouped in two main classes:

OEM or integrated modules  – for automated teller machines and point of sale terminals:

  • to encrypt the personal identification number (PIN) entered when using the card
  • to load keys into protected memory

Authorisation and personalisation modules:

  • check an on-line PIN by comparing with an encrypted PIN block
  • in conjunction with an ATM controller, verify credit/debit card transactions by checking card security codes or by performing host processing component of an EMV based transaction
  • support a crypto-API with a smart card (such as an EMV)
  • re-encrypt a PIN block to send it to another authorisation host
  • support a protocol of POS ATM network management
  • support de facto standards of host-host key|data exchange API
  • generate and print a “PIN mailer”
  • generate data for a magnetic stripe card (PVV, CVV)
  • generate a card keyset and support the personalisation process for smart cards

The major organization that produces and maintains standards for HSMs on banking market is the Payment Card Industry Security Standards Council.



Cryptographic Key Management

Impact, Likelihood and Risk Rating

Impact, Likelihood and Risk Rating


The first step is to identify a security risk that needs to be rated. The risk assessor needs to gather information about the threat agent involved, the attack that will be used, the vulnerability involved, and the impact of a successful exploit on the business. There may be multiple possible groups of attackers, or even multiple possible business impacts. In general, it’s best to err on the side of caution by using the worst-case option, as that will result in the highest overall risk.

Likelihood RATING


There are a number of factors that can help determine the likelihood. The first set of factors are related to the threat agent involved. The goal is to estimate the likelihood of a successful attack from a group of possible attackers. Note that there may be multiple threat agents that can exploit a particular vulnerability, so it’s usually best to use the worst-case scenario. For example, an insider may be a much more likely attacker than an anonymous outsider, but it depends on a number of factors.

Note that each factor has a set of options, and each option has a likelihood rating from 0 to 9 associated with it. These numbers will be used later to estimate the overall likelihood.

The first set of factors are related to the threat agent involved. The goal here is to estimate the likelihood of a successful attack by this group of threat agents. Use the worst-case threat agent.

Threat Agent Factors


Skill Level

How technically skilled is this group of threat agents? Security penetration skills (9), network and programming skills (6), advanced computer user (5), some technical skills (3), no technical skills (1)


How motivated is this group of threat agents to find and exploit this vulnerability? Low or no reward (1), possible reward (4), high reward (9)


What resources and opportunities are required for this group of threat agents to find and exploit this vulnerability? Full access or expensive resources required (0), special access or resources required (4), some access or resources required (7), no access or resources required (9)


How large is this group of threat agents? Developers (2), system administrators (2), intranet users (4), partners (5), authenticated users (6), anonymous Internet users (9)

Vulnerability Factors


The next set of factors are related to the vulnerability involved. The goal here is to estimate the likelihood of the particular vulnerability involved being discovered and exploited. Assume the threat agent selected above.

Ease of Discovery

How easy is it for this group of threat agents to discover this vulnerability? Practically impossible (1), difficult (3), easy (7), automated tools available (9)

Ease of Exploit

How easy is it for this group of threat agents to actually exploit this vulnerability? Theoretical (1), difficult (3), easy (5), automated tools available (9)


How well known is this vulnerability to this group of threat agents? Unknown (1), hidden (4), obvious (6), public knowledge (9)

Intrusion Detection

How likely is an exploit to be detected? Active detection in application (1), logged and reviewed (3), logged without review (8), not logged (9)

The overall Likelihood rating could be determined by taking the average of all factors.  Based on the average score, you can map it to a single likelihood rating by using the below table:




The business impact requires a deep understanding of what is important to the company running the application. The business risk is what justifies investment in fixing security problems.

Financial Damage

How much financial damage will result from an exploit? Less than the cost to fix the vulnerability (1), minor effect on annual profit (3), significant effect on annual profit (7), bankruptcy (9)

Reputation Damage

Would an exploit result in reputation damage that would harm the business? Minimal damage (1), Loss of major accounts (4), loss of goodwill (5), brand damage (9)


How much exposure does non-compliance introduce? Minor violation (2), clear violation (5), high profile violation (7)

Privacy Violation

How much personally identifiable information could be disclosed? One individual (3), hundreds of people (5), thousands of people (7), millions of people (9)

The overall Business Impact rating could be determined by taking the average of all factors.  Based on the average score, you can map it to a single impact rating by using the below table:


Risk Rating Presentation


The old adage mentions that Risk = Impact * Likelihood.  Even though this is true, a mathematical multiplication of compartmentalized Impact and Likelihood ratings often gives a Risk Rating which does not reveal the actual gravity behind the risk.

The best way to present the gravity of a risk seems to be to explain the Business Impact of the risk along the lines of below four factors, as this is what a Business Owner can directly relate to:

  • Financial Damage
  • Reputation Damage
  • Non-Compliance
  • Privacy Violation

The likelihood of the risk taking place is best explained through the five levels and their real life examples:

  • Certain – Toe Injury
  • Likely – Fall
  • Possible – Major Car Accident
  • Unlikely – Aircraft Crash
  • Rare – Major Tsunami

An excel guide to help arrive at the likelihood rating and optionally, the impact rating is available at: 


Impact, Likelihood and Risk Rating

IT Security Requirements for a new IT System

IT Security Requirements for a new IT System

Ownership and Criticality of the System:

Business Owner (Name, Department and Designation);

IT System Manager (Name, Department and Designation);

Project Manager;

Project Name;

Cost Charge Code;

Confidentiality, Integrity and Availability rating of the System (Define Worst Case Impact if each of the components is affected).

Availability rating should determine the RTO and RPO of the system.

Describe the scope of change introduced by the project.

Describe the purpose of the system and its functions.

Describe the user base of the system.

Provide inter-system (between different systems) connectivity diagram.

Provide intra-system (within the system) connectivity diagram.

Indicate the Datacenter (DC) where each system is hosted.

Data-In-Motion Encryption – All data transfer from component to component should be using secure protocols which provides encryption of the data being transferred (SFTP, FTPS, Secure-JDBC, SSL, SSH, etc)

Data-At-Rest Encryption:

Option 1 – Application Server level encryption of data before storing into Database (Application administrators have full access to data)

Option 2 – Database level encryption of data (Application administrators and DBAs have full access to data).

Option 3 – Disk/SAN level encryption of data (Application administrators, DBAs and OS administrators have full access to data).

Password Controls:

Password should enforce the inclusion of Uppercase, Lowercase, Number and Symbol.  Enforce the non-usage of past 10 passwords.  Enforce password expiry for every 90 days.  Passwords must use a minimum of 15 characters.

[Guidance: Use Passphrases instead of a word.  Example: IHave1cat&ILoveIt! ]

Two-Factor Authentication should be used for access to application/systems over the Internet.  The second factor being SMS OTP or Hardware Token OTP.

Transaction Signing (OTP generated from Hardware Token based on input value related to the transaction or input value sent through SMS) should be used for authorizing financial transactions and for changing of critical customer data, over the internet.

Session Inactivity:

(i) [Optional] The session should be locked after a pre-defined period of inactivity;

(ii) The session should be logged-out after a pre-defined period of inactivity;

Confidential data at Endpoint Devices:

Confidential data should not be stored into disk storage in Endpoint devices, without a strong Need-To-Have.  If there is a strong Need-To-Have, the data should be stored into Encrypted Containers and the Integrity of the Container should be verified before the data is re-used by the application.

Cache at Endpoint Devices:

Cache used in endpoint devices should be cleared when the application logs out.

Critical Processes at Trusted System:

Input Validation, Output Encoding, Authentication, Authorization, Session Identifier Creation, Cryptographic Functions to protect secrets from Application User and Logging Controls should be implemented at the Trusted System – at the Server side; and not at the User Endpoint.

Authentication should be required for accessing each page and resource at the server side, unless public usage is intended. 

Access Control:

Please provide Access Roles-Permissions Matrix (including Business and IT).  Please indicate which Roles are classified as Privileged Roles.

Security Logging:

Process for recording, protection, retention, ~review of security logs (login/logout, change to access rights, security configurations, etc) should be established.

Activity Logging:

Process for recording, protection, retention and ~review of activity logs should be established.

Secure Coding Practices:

Use OWASP Secure Coding Practice Quick Reference Checklist during code development and review.

Integrity of Golden Source Data:

Any data that is received by the application to be used as a golden source should be integrity verified by the Business Owner.

Network and Application Penetration Testing:

Internal Network and Application Gray Box Penetration Testing should be performed for Internet Facing Systems and Critical Internal Systems before Go-Live.

Platform Vulnerability Assessment:

Platform (OS, DB, and Device) vulnerability assessment should be performed before System Go-Live.

Anti-Malware Protection:

Anti-Malware Solutions should be installed on all Wintel Platforms supporting the System.

Support Documentations:

Documentations should be created to ensure that there is adequate information to support ongoing operations, problem resolution and future maintenance of the system.

Project Level IT Security Requirements (Non-Functional Requirements) –

IT Security Requirements for a new IT System

Responsibility Assignment Matrix – RACCI Matrix

Responsibility Assignment Matrix – RACCI Matrix

The Responsibility Assignment Matrix (RACCI Matrix) describes the participation by various roles in completing tasks or deliverable for a project or business process.  It is especially useful in clarifying roles and responsibilities in cross-functional/departmental projects and processes.

Responsible (Recommender / Driver / Performer) – Those responsible for the performance of the task. There should be exactly one person with this assignment for each task.

Accountable (Final Approving Authority)  – The one ultimately answerable for the correct and thorough completion of the deliverable or task, and the one who delegates the work to those responsible.

Consulted (Contributor / Counsel) – Those whose opinions are sought; and with whom there is two-way communication.

Control – The person/function reviewing the result of the activity (other than the accountable). He or she has a right of veto; his or her advice is binding.

Informed – Those who are kept up-to-date on progress; and with whom there is one-way communication.

Responsibility Assignment Matrix – RACCI Matrix

Control Windows 10 Migration Push from Microsoft

Microsoft is pestering its Windows users by constantly displaying the “Migrate to Windows 10” icon in the taskbar.  It is even presenting the Windows 10 migration as an Optional “upgrade” in Windows Update module.  Attempts to opt-out/hide the “Optional upgrade” is not being registered by Windows and the “upgrade” still appears.

If you are one of those users who are annoyed by how hard Microsoft is trying to get you migrated from your current working OS version to Windows 10, you are not out of luck.

Install the GWX Control Panel tool from .  This tool allows to completely control the “Migrate to Windows 10 nag” from Microsoft and helps you regain your peace of mind.

GWX Control Panel

Control Windows 10 Migration Push from Microsoft