Compliant Internal Test

Print this Page	2.8 Compliance 15. Compliant Internal Test	Close this Page

2.8.15. Compliant Internal Test

Authorized users may sign in and use hacking techniques to exploit weaknesses in data entry forms to access and change data that they have no right to access. The purpose of internal testing is to assume that authorized users cannot be trusted, have criminal intent to defraud, steal data and corrupt the application - testing will identify what security vulnerabilities the authorized user could exploit.

In a perfect world, all valid user behaviour should be processed as normal and any hacker's behaviours should blacklist that users profile to prevent any other attack. As the application service provider program architecture has evolved over ten years to include experience from hundreds of people around the world, unauthorized user actions can be detected and prevented.

2. Monitoring

Every authorized user is fully aware that when they sign in they identify themselves and everything they do is permanently recorded in the "What Did I Do" audit trail and this is monitored by their manager. Every user is aware that each and every field value they change is permanently recorded as history and this history can be viewed by other users. In this context, where a managed user is monitored using hackers techniques such as SQL injection or URL manipulation, then they will be prevented from ever signing into the application in the future.

3. Intrusion Detection and Prevention Techniques

The foundation architecture of the application has built in layers of security that have evolved to ensure that criminal techniques will be detected and such users prevented from using the application. Many of the layers of security that are built into every program are a trade secret, but for the purpose of internal penetration testing, some topics will be disclosed.

It is not practical to carry out internal penetration tests on a production environment - each penetration test would be detected and stopped. A different artificial developmend and test environment must be created to enable each set of penetration tests to take place. For example, to test who can sign in from countries like China at 04:00 on a Sunday, a special infrastructure environment must be created before such tests can take place. To test a SQL injection method requires a facility that will enable the SQL script to be input to the application and to detect how far into the application it gets before it is rejected - special logging may be required. In all cases, normal production cryptographic has functions must be disabled to enable any such testing to begin.

9.3.1 Compensating Controls

While cheap web sites may try to operate all kinds of software on the same computer, this means the whole web service is only as secure as the weekest software utility installed - many tools like Adobe Reader have hundreds of vulnerabilities that may be exploited by a hacker. The application service provider operate dedicated servers without any client networked computers and where each server does one and only one job. web servers with one program and no other installed software is as safe an architecture as it is possible to design. Application servers that are not connected to the Internet and have internal private networks to the web servers and database server is as safe an architecture as it is possible to design. Database server that has a private network connection to the application servers and no other computer means that every SQL stored procedure request must come from an application server and not a hacker.

This architectural compensating control makes PCI-DSS compliance practical because the architecture matches the threat with a control to neutralize the risk. By eliminating all ancillary services from each dedicated server, the risk of an attack is virtually eliminated and dramatically reduced.

9.4 Sign In

The weakest security part of any application service is its users and user sign in. User are expected to remember three distinct pieces of data as: (1) sign-in handle as a mnemonic of the user name that can be up to 32 characters long; (2) unique private email address that may be up to 64 characters long and must conform with the rules of email formats; and (3) an assigned pass phrase of up to 32 characters. In addition, each user must sign-in between certain times of the day and days of the week from an identified network using an identified browser.

Testing the strength of passwords can be automated with many tools that can be downloaded, but few will be tuned to mirror the authentication requirements of the application with its proven raft of measures that combine to defeat crackers. A brute force cracking tool may be tried, but for the majority of the time, the tool will fail just because it's the wrong time of day or day of week or country. As all sign-in is conducted by a new session over an encrypted network, it hard to imagine how a cracker could expect to win. Many layers of security are applied including:

9.4.1 Sign In Handle

Each user is assigned a unique sign in handle that is NOT the same as their name on their business card. While this is not secure data, it is private and must not be disclosed. The style, format and size is restricted to make it easy for the user and hard for the criminal to attack.

9.4.2 Email

Each user must enter their private email address - an email address that is password protected using Hotmail, Gmail or some other safe and secure cloud based email service. The users email address that is on their business card should not be used as that may be used by criminals to attack the application.

9.4.3 Pass Phrase

Each user is assigned a memorable phrase or saying that is case sensitive and will contain upper and lower case characters, numbers and symbols. The pass phrase should not contain any word that can be found in a dictionary, or is a name or a place.

No authorized user has the right to change their own pass phrase; the risk of reusing a password that may be cracked in another application is too great.

9.4.4 Mode

Each user must select the sign in mode that they have been authorised to select and selections of the wrong mode will be treated as a failed sign in attempt.

9.4.5 Time of Day

Each user is permitted to sign in between certain hours of the day. Any attempt to sign in outside these normal business hours will be treated as a criminal hacking attack.

9.4.6 Day of Week

Each user is permitted to sign in on selected days of the week. Any attempt to sign in outside these normal business days will be treated as a criminal hacking attack.

9.4.7 Country (Geo-Location)

Each user is permitted to sign in from an IP address that is registered in the users own country. Any attempt to sign in using an IP address that is registered to a different country will be treated as a criminal hacking attack.

9.4.8 ISP Name

Each user is permitted to sign in using a network provided by a named Internet Service Provider. Any attempt to sign in using a network provided by a different ISP will be treated as a criminal hacking attack. Staff can be prevented from signing in from their home network when this is not permitted.

9.4.9 IP Address

Each user is permitted to sign in using an approved IP address or range of IP addresses. Any attempt to sign in using a different IP will be treated as a criminal hacking attack.

9.4.10 Operating System

Each user is permitted to sign in using any computer, smart phone or tablet with an approved operating system. Any attempt to sign in using a different operating system will be treated as a criminal hacking attack. For example; a user can be approved to only use a MAX OSX or WXP operating system.

9.4.11 Browser

Each user is permitted to sign in using any computer, smart phone or tablet with an approved browser. Any attempt to sign in using a different browser will be treated as a criminal hacking attack. Staff can be prevented from using Firefox with its hackers add-in tools.

9.4.12 Cookies

Certain roving users may be trusted and assigned a set of cookies on their computer that is then granted the right to sign in from any country.

9.5 Pass Phrases

With more than ten years experience with thousands of users, the application service provider can safely state that pass phrases are too important to be left to be assigned by the user. When a user was permitted to set their own password, they choose the same password as they used for all kinds of other applications, including their Saga gaming account. When the Saga gaming application was cracked, many millions of user passwords flooded onto the Internet and were found to have identical email addresses. The security of the application cannot be compromised by failures of another application in releasing user assigned email and password combination.

9.6 Encryption

The computer press endless go on about pass phrase encryption, but it is generally taken out of context of a professionally designed and operated Internet application. To state the facts:

The actual sign in page that is shown to visitors is dependent on the visitors geo-location data. If the visitor has requested the sign in from an IP address in a country that is not supported, then they are shown a sign in page where all data entered will be ignored. A white list of approved IP addresses is supported to handle the odd exception that has been found in the last ten years. A black list of known hackers IP addresses is maintained to ensure they never see the real sign in page.

The three pieces of visitor entered data and the selected mode are encrypted by the user browser and sent to the server.

The sign in name is sanitized according to sign in name rules. The email is sanitized and validated as a valid email format. The sign in name, email address, hour of the day, day of week and IP data is sent to the database server to find a matching user record. If one and only one record matches the search criteria, then the hashed password is returned to the application server. The application server program will then hash the pass phrase and match it against the database hashed password - if it is identical, then the user has been authenticated and the welcome page can be shown. If any other result is found, then the sign in page is shown. Every page request is written to the WDID audit trail.

So the cracker has to begin with a published email address. This is becoming more and more difficult as people move from the old one-computer-per-desk to have many email addresses - users are encouraged to use their private email addresses rather than their published email addresses. All head off staff are assigned bespoke email addresses that are not used for any other purpose.

The cracker then moves on to a sign in name as a mnemonic or handle - in many cases people close to the target will know a persons handle, but to a remote cracker this intelligence should not be on Facebook.

Finally the cracker will try all the usual names with numbers - all the traditional pets, stars and Facebook passwords that are specifically excluded from the application service. So many cracking tools appear to guess hashed values - why? Only the sign-in logic on an application server is able to create the hash of the input data and compare it with the hashed database value, so external cracking tools may be aimed as applications that work differently to the application service.

9.7 Password Cracking

When a user enters a password, a hash of the entered password is generated and compared with a stored hash of the user's actual password. If the hashes match, the user is authenticated. Password cracking is the process of recovering passwords from password hashes stored in a computer system or transmitted over networks. It is usually performed during assessments to identify accounts with weak passwords. Password cracking is performed on hashes that are either intercepted by a network sniffer while being transmitted across a network, or retrieved from the target system, which generally requires administrative-level access on, or physical access to, the target system. Once these hashes are obtained, an automated password cracker rapidly generates additional hashes until a match is found or the assessor halts the cracking attempt.

One method for generating hashes is a dictionary attack, which uses all words in a dictionary or text file. There are numerous dictionaries available on the Internet that encompass major and minor languages, names, popular television shows, etc. Another cracking method is known as a hybrid attack, which builds on the dictionary method by adding numeric and symbolic characters to dictionary words. Depending on the password cracker being used, this type of attack can try a number of variations, such as using common substitutions of characters and numbers for letters (e.g., p@ssword and h4ckme). Some will also try adding characters and numbers to the beginning and end of dictionary words (e.g., password99, password$%).

Yet another password-cracking method is called the brute force method. This generates all possible passwords up to a certain length and their associated hashes. Since there are so many possibilities, it can take months to crack a password. Although brute force can take a long time, it usually takes far less time than most password policies specify for password changing. Consequently, passwords found during brute force attacks are still too weak. Theoretically, all passwords can be cracked by a brute force attack, given enough time and processing power, although it could take many years and require serious computing power. Assessors and attackers often have multiple machines over which they can spread the task of cracking passwords, which greatly shortens the time involved.

Password cracking can also be performed with rainbow tables, which are lookup tables with pre-computed password hashes. For example, a rainbow table can be created that contains every possible password for a given character set up to a certain character length. Assessors may then search the table for the password hashes that they are trying to crack. Rainbow tables require large amounts of storage space and can take a long time to generate, but their primary shortcoming is that they may be ineffective against password hashing that uses salting. Salting is the inclusion of a random piece of information in the password hashing process that decreases the likelihood of identical passwords returning the same hash. Rainbow tables will not produce correct results without taking salting into account, but this dramatically increases the amount of storage space that the tables require. Many operating systems use salted password hashing mechanisms to reduce the effectiveness of rainbow tables and other forms of password cracking.

Password crackers can be run during an assessment to ensure policy compliance by verifying acceptable password composition. For example, if the organization has a password expiration policy, then password crackers can be run at intervals that coincide with the intended password lifetime. Password cracking that is performed offline produces little or no impact on the system or network, and the benefits of this operation include validating the organizations password policy and verifying policy compliance.

9.8 Password Expiry

As a general rule, the application service provider assigned passwords do not expire because a password cracker working for a year is not going to crack an assigned pass phrase. Each and every attempt by a cracker is recorded in the audit trail, so the intensity of any attack can be determined and a specific user may be assigned a new sign in handle, private email address and new pass phrase if the need should arise.

9.9 Functional Access Control

When a new user is authorized to sign in, they are authorized by their senior manager to have very specific data and functional access controls - the senior manager takes person responsibility for what they can authorize each new user to what functions they can use and what data they can access. This matrix of functions and data cannot exceed the rights granted to the senior manager.

Each authorized users will have unique skills and responsibilities that could mean that they end up with a unique matrix of data access controls and functional access controls, however some generalizations can be made:

9.9.1 Agent

A significant part of the application is devoted to Agents data entry facilities. Agent's data could be simplified as: Clients, Vessels and Policies; however this core is supported by many other kinds of data with a total of just over 100 unique fields. Agents only have access to data that they personally authored - they cannot see any data entered by any other Agent and they will not be aware that any other Agent exists. Each Agent is the responsibility of one Agent-Manager who is permitted to share the Agents data so they can carry out validation checks. Agents are authorized to work from France and Greece and no other country.

9.9.2 Agent-Manager

Any numbers of Agent-Manager offices are supported and each Agent-Manager will employ any number of Agents. Each Agent-Manager shares data with their own Agents, but not with any other Agent-Manager - each Agent-Manager has no reason to know that any other Agent-Manager exists. A Agent-Manager can share any Agents policy data with a Cover-Holder for the purpose of requesting a quotation. The Agent-Manager can change a few field values in a Agents policy or add a note, but they do not author new client data. A Agent-Manager can authorize any number of Agent-Manager users and Agents for their own office. Agent-Managers are authorised to work from networks in France and Greece and no other country.

9.9.3 Cover-Holder

Any numbers of Cover-Holders offices are supported and each Cover-Holder has no reason to know that any other Cover-Holder exists. Each cover-Holder will be aware of Agent-Managers who may wish to share Agents policy data for the purpose of approving a quotation. The Cover-Holder can change a few field values in a Agents policy or add a note, but they do not author new data. A Cover-Holder can request Agent data to be shared with an Owner for approval purposes. A Cover-Holder Manager can authorise any number of Cover-Holder users for the own office. The Cover-Holder and all its users must work from an approved UK network during normal business days and hours.

9.9.4 Owner

Any numbers of Owner offices are supported and each Owner may not be aware of any other Owner. The Owner will be aware of their Cover-Holders and will share Agent data for the purpose of approving a quotation. An Owner can authorize any number of Owner users to work from an approved UK network during normal business days and hours.

9.10 Multiple Sign In

Modern people with a range of computing devices may be authorised to sign in to many devices at the same time. A Agent may employ the browser on their smart phone and a browser on their laptop to sign in at the same time - some work can be done easily on a smart phone, while other work is best suited to a laptop. It is NOT treated as a security violation for the same person to be signed in using multiple devices at the same time; however everything depends on how their user profile is configured. Where a user is only permitted to use a specific operating system and specific browser on the same network, they may find that their mobile phone and their laptop are not compatible.

In the event that a user computer fails for any reason, that user can simple switch on their backup computer, sign in and continue work. The fact that their broken computer is still signed in does not cause the user any concern. The broken computer session will be automatically signed off later in the day.

9.11 Sign Off Delay

Each user is assigned a sign off delay time that is typically one hour, but this may be upgraded to "all day" when the Agents dashboard is open. Every page request made by every user is monitored and recorded; when a user has not made a page request for one hour, they may be automatically signed off. A user cannot detect that they have been signed off until they try to click on something and find that the current page is replaced by the home page without any warning.

During the working day, authorized users who would normally be signed in all day long may be assigned a dashboard with valuable real-time statistics that are automatically refreshed. The act of refreshing this dashboard information is restricted to 08::00 to 18:00 each day; but during this time, while the dashboard is open, the user cannot be signed off because the dashboard refresh is a normal page request that keeps the user active.