| 2.3.16. Risk Assessment: | | Over the last decade, a single consistent architecture have been relentlessly refined and improved to eliminate defects. It is acceptable to have a much higher development cost, where the deliverables have a much lower defect rate and are provably more flexible. Fourth generation languages that were first published in 1980 have been integrated into a quality management framework of proven procedures to ensure that the art of development has been reduced to automated tasks that after so many years, have evolved to minimise defects. |
| 5.2 Development Methodology | | An application designed to be extremely flexible and very secure by the strict insistence of a proven Information Engineering Methodology (IEM) will always be much better than ad-hoc agile programming. Programming is too important to be left to programmers; it is an engineering discipline that must be managed from the top down to deliver provably complete and correct solutions. | | It may costs ten times more to maintain and application than to develop it in the first place, so every opportunity must be taken to simplify maintenance. Whenever a trade-off can be taken to swap logic for data, then that decision will always favour a data driven approach. |
| 5.2.1 Single Program Application Stack (SPAS) | | The number of programs in a web site application stack provides an indication of the scope of possible vulnerabilities and were penetration testing is needed. The application service provider have chosen to implement the Single Program Application Stack (SPAS) web server architecture to eliminate many of the traditional vulnerabilities that hackers could exploit. With only one web server program that is exposed to the Internet and all network traffic, it is much easier to be secure and it demonstrates to the hacker that an advanced security policy is in-place. Every hacking attempt at the one program will be detected and the criminal hacking attack stopped with the user blacklisted to prevent further hacking attacks. |
| 5.3 Quality Management System | | Over many years, every task has been reduced to a documented procedure and so every delivery has a pedigree of what it was based on. If a defect is uncovered, then the procedure is wrong and must be corrected before the code is corrected - the quality manual is 100 times more valuable than any application. | | A typical application may have 1000 components, so release levels are meaningless and the life cycle of each component must be managed. Some components will not change for many years, but who wrote it and what procedures they employed is critical background information before any improvements can be applied. |
| 5.3.1 Compensating Controls | | PCI-DSS permits the use of "compensating controls" to replace traditional security controls where the threat analysis makes it reasonable to do so. For example, a PCI-DSS control is to emply anti-virus software where applicable, but a dedicated database server that is not connected to the Internet may have a compensating control where all services other than the DBMS are disabled. Where the threat of geting a virus is so low and where the operations are such that a virus could not operate, then the compensating control is a cut down and locked down DB operating system that does not need and would become more vulnerable if anti-virus software was installed. |
| 5.4 Avoiding Security Issues | | Security papers are release every day highlighting what does go wrong with web sites in graphic detail. It is the role of the application service provider Security Manager to understand what can go wrong and to learn the lessons before it happens to the application. |
| 5.4.1 Cross Site Scripting (XSS) | | Cross site scripting defects occur when an application takes user entered data and sends it back to a web browser without first sanitizing the data value. XSS enables a criminal to enter a script as if it was data and when that script is executed in a web browser then the criminal can gain control of the users secure session. If a user enters the wrong data, it is critical that the application does NOT respond by showing the data they have entered incorrectly - that incorrect data may be a malicious cross site script. It is hard to imagine why such a simple problem causes more web site failure in the world that anything else - day one of any web masters course will explain how to totally avoid the problem. | | The application service provider have monitored XSS vulnerabilities for the last ten years and have evolved a powerful data entry sanitization function that removes any malicious XSS code. Microsoft publish an Anti-XSS library using Request Query String to resolve XSS issues - the application service provider have their own version using htmlentities that ties in directly with the data dictionary of permitted values that is part of every application. | | The application service provider have procedures to resolve three kinds of XSS as: (1) reflective, stored and DOM. Reflected XSS is most common where bad input is shown back to the user when that bad input could contain the worst kind of JavaScript procedure that could cause devastation. Stored XSS is where a forum accepts user free format text and that data is then shown to another user including the imbedded JavaScript procedure that could cause chaos on the users computer. Data Object Model (DOM) attacks enable parts of a screen to be manipulated by criminals, but in all cases it is more of a distraction than a serious criminal threat to operational data. | | To test the compliance, XSS has been undertaken by entering onmouseover=prompt("terry was here"). Another popular hack is to enter onmouseover=(document.alert). These examples provide justification why symbols are rarely accepted in data entry and field maximum size rarely exceeds 32 characters. |
ASP policies and rules include: | | 1. Input validation using a common reusable function that is the only method to accept data into the application. Every field value must match it data dictionary specification for minimum and maximum length, format and permitted values. Any data that could be an attack is simply deleted and ignored without the satisfaction of an error message. | | 2. Output encoding to HTML is undertaken using a common reusable function that is able to change symbols into their HTML equivalents so bad logic that would require a quotation mark finds it is replaced with the equivalent HTML tag that cannot be made harmful. | | 3. Output web pages are always encoded as UTF-8 so an attack cannot be made by switching encoding to Japanese or some other exotic codepage. |
| 5.4.2 SQL Injection Defects. | | Injection defects are very common in web applications where user entered data is sent to the database without being sanitized. A criminal with a little SQL knowledge can format data to be entered into a field that can cause a database to be deleted, or spill out its contents. This is the type of programming error that could be expected of a 16 year old novice, but it continually hits the headlines from major corporations. Criminals have devised an endless set of injection methods, but they all boil down to one programming defect of using any user supplied data before ensuring it is 100% clean | | The application service provider have understood injection threats for the last 20 years and have evolved a method of ensuring that only permitted data values are sent to the database. The development methodology of all fields being defined in detail in a data dictionary provides dynamic validation information for each and every data entry point in the application. | | The classic injection defect is where a "*" is used in a password field and where the database is designed to return all records because "*" is classified as a wildcard character. Day one of web master school will teach people not to permit any wildcard symbol in a password. Day two should also teach people that when more than one record is returned from the user profile table, then sign-in should be declined. |
ASP policies and rules include: | | 1. Input validation using the reusable anti-XSS function so data is only accepted when it conforms to documented data dictionary standards. | | 2. Use strongly typed parameterized query API for stored procedures - if any defect is identified, reject the request. | | 3. Enforce least privilege when connecting from the web server to application server or application server to database server. The database server is configured to only accept stored procedure requests from an application server and no other machine. The application server is configured to only accept procedural requests from a local web server and no other source. | | 4. Avoid error messages that may be valuable information to a criminal - every superb application has been found to have virtually no way for a user to make an error. | | 5. Use stored procedures and nothing but stored procedures. Ad-hoc queries serve no business requirement because a management report can be created and reused time and time again. The overall application design defines what data can be accessed by what user roles and implementation is effectively implemented without any possibility of a programmer accidently overstepping what is permitted. | | 6. Do not use dynamic query interfaces without logging or any form of control. Once an application is ready for operational life, no justification can be identified for a business intelligence or query reporting utility. | | 7. Input validation must be strong, not just a list of string replacement statements. "mysql_real_escape_string" was the technique used before the days of PHP Data Objects Server (PDOS). |
| 5.4.3 Malicious File Execution | | Application logic that is vulnerable to file inclusion allows a criminal to include hostile logic and data that may compromise a complete server. | | The application service provider understand the threat and have a policy never to accept filenames or files from users. Where any data entry is involved, the values being entered must be subject to exacting data dictionary definitions for permitted values and that will always exclude any kind of malicious filename. | | Every included program construct is only included using a declared constant that cannot be changed in any way. No user data entry could cause a library to be included. | | Where a forum upload may enable a PDF or PNG file to be uploaded, every other kind of file is rejected as a criminal may then be able to cause that file to be executed and do untold damage. Because of the threat implied from uploaded documents, all such documents are stored on a different physical computer that if compromised, would have very little impact on the overall application. | | Uploaded files are saved using a system generated file number (without file type) that is not known to the author - this prevents a criminal from executing the uploaded file as they do not know where it is stored and what it is called. It is safe to download back to a user an uploaded file, but to show the file contents to the user is a potential threat unless the file content has been verified as being an simple image or raw text. |
ASP policies and rules include: | | 1. Strong validation of user data entry values to ensure that a file name is consistent and real. | | 2. Add firewall rules to prevent web servers making additional connections to external web sites because of imbedded header information. Ensure that internal processing is undertaken by the application server that cannot be made to connect to the Internet. | | 3. Replace all files names with a strong internal numbering system and treat original file names as low quality free format text. | | 4. Always store user uploaded files in a different location to critical business data and certainly not near a database server. Business documents that are created by the application can be fully trusted, but no user supplied files can be fully trusted and must be sandboxed. | | 5. Disable the ability for a web server to file open and allow a URL include - PHP must be correctly configured to ensure that a rogue file cannot create communications with the Internet. A benefit of running thousands of Internet applications for so many years is that these problems have been found, have been resolved and will not return. |
| 5.4.4 Insecure Direct Object Reference | | A direct object reference occurs when an application discloses a reference to an internal implementation object such as a file, program or database record as a key, URL or form parameter. In theory, a criminal could manipulate these referenced to access other objects without authorization. | | The application service provider appreciate the threat level, but implement other layers of security to protect against criminals using this kind of attack. For example, risk number 123456 may be shown to a user and the user may guess that risk number 123455 and 123457 may also exist. The threat is not in showing objects, but from enabling a user to do something from the information they are guessing at. URL manipulation is prevented by it being so easy to identify, so this apparent threat turns out to be resolved by other development techniques. |
ASP policies and rules include: | | 1. User data entry is never used to identify an include file - include library names are hard codes as declared constants that cannot be dynamically changed. | | 2. A criminal is not able to use a string such as "../../../etc/password" to access a different folder on a server - every folder has exacting permissions assigned and "null byte injection" is prevented by providing no mechanism to enter data using URL parameters. | | 3. URL will not say "scheme=123" in such a way that a criminal could change the URL to say "scheme=122" on the assumption that another scheme may exist. | | 4. Data access controls, functional access controls and good security principals have continually evolved to deliver a consistent method of working that does not have any of the traditional defects. That is not to say things are perfect, just that continual improvements have been applied at the architectural level to avoid the defects made by others. |
| 5.4.5 Cross Site Request Forgery (CSRF) | | A clever CSRF attack forces a sign-in user to send a pre-authenticated request to a vulnerable web application which then forces the user"s browser to perform a hostile web request for the benefit of the criminal. This class of vulnerability is critical to online banking where people with infected computers and susceptible to social engineering suggestion can get trapped into a "man in the middle" criminal web site. | | The application service provider implement session level security where any error will terminate the session. While a user session is active, the user browser employs secure HTTPS requests that are good enough to stop any CSRF criminal. Even where the user"s computer is infected with the worst kind of malware, that client-side malware cannot attack any server-side programs over an encrypted communications line. |
ASP policies and rules include: | | 1. Cookies are not used to identify users and do not hold user identifying data. | | 2. Source IP addresses are not used to exclusively identify users. | | 3. "Remember Me" gimmicks are not implemented. User of a single sign-on utility based on Kerberos or active directory is not permitted. | | 4. Users will be signed off at the end of each session and a session cannot go past midnight. The use of users being signed on for many days at a time as used by Yahoo and others is not permitted. | 5. Where a computer web page is compromised such as:
<img src = http://www.example.com / do_this_now.php> | | This causes the user viewing the web page to execute the "do_this_now.php" program using their live session credentials. The application service provider avoid such class of vulnerabilities by not having any programs that a criminal could reuse such as "do_this_now.php". | 6. Black hat books on the subject give real world examples that are a lesson for us all to learn - for example:
<img src = "http://www.example.com / transfer.aspx? frmAcct = document.form.frmAcct &toAcct = 495867485 &toSwift = 3948576 &amt = 9999.99"> | | 7. The significance of this kind of attack high and so rules have evolved to insert extra hidden fields into a POST form and to avoid the use of GET. Out of band random tokens in a form that cannot be seen by the criminal make enable extra validation to be made and any slight change in tokens identified to reject the request. |
| 5.4.6 Information Leakage and Improper Error Handling | | Applications can unintentionally leak information about configuration, internal workings or violate privacy though a variety of application problems. Criminals feed on snippets of leaked information to build up an attack surface to steal data. | | The application service provider has a simple rule to move towards no error messages. When a user fails to sign-in correctly, no error message is shown that would give a criminal a clue if the cause is the sign-in name, password or time of day. Not all error messages have been eliminated, but with due diligence the few that remain do not provide any private information to a criminal. |
ASP policies and rules include: | | 1. Error messages including stack and SQL traces are never permitted in an operational application. Debugging totally stops when an application is in production. | | 2. Functions show an identical behaviour following any error condition - in general the application behaves as if the error had not taken place. This is the only certain way not to provide valuable attack information to a criminal. | | 3. Every programmer shares the same common error handling function and calling architecture - nobody is permitted to do their own thing. | | 4. If the error is detected by the database layer or the application layer or the web layer, the error message is identical so a criminal is not given a clue as to how the attack was detected. | | 5. Browser error handling can be improved with a common reusable web page that tells the criminal nothing and overrides the standard browser informational error page. Security by Obscurity is a valuable extra layer of defence. |
| 5.4.7 Broken Authentication and Session Management. | | User profile data may not always be properly protected and a criminal may compromise passwords to assume a user identity. A user who is permitted to enter their own password, may use the same password for Facebook, Twitter, Email and their Saga gaming account, then that password is stolen then criminals can simply impersonate the user with a valid password. Hundreds of password cracking utilities can be downloaded from the Internet to try 200,000 common names that people tend to use as passwords. | | The application service provider full understand that pass phrases are too important to be left to each user and pass phrases must be generated by the application and assigned to each user. The pass phrase is not goo enough without extra IP and ISP checking, time of data checks and day of week checks. Experience demonstrates that hundreds of hacking attempts are made every evening or early morning, so the simple sign in limitation of 8am to 6pm provided a valuable extra layer of security. The application service provider implement a number of security techniques including geo-location to protect applications. A white list and black list of approved and rejected computers are also managed. |
ASP policies and rules include: | | 1. The real problems with authentication are not sign-in, but forgotten password procedures, time out procedures and secret question games that are poorly conceived, poorly designed, poorly implemented and poorly tested. | | 2. Any system that permits a user to define their own password is bound to fail - that password has already been compromised for that user by another application. Passwords are too important and must be created by the system using strong password rules and assigned to each user. | | 3. Passwords such as "Chelsea1" may pass the rules of upper and lower characters and a number, but many millions of people have that same password. Your cat may have a strange name, but brute force utilities will eventually be able to guess your cats name. No part of any password must be permitted to contain a word or name found in a dictionary of encyclopaedia. | | 4. Secure passwords must contain symbols, but only some symbols are permitted to the rules of what makes a good secure password are too complex to expect the average user to be able to get it right. | | 5. The emergence of question and reply password games has created new games to be played while waiting for your train - guess somebody else"s subjective reply to five questions. The prize is the ability to change somebody"s password to demonstrate your prowess in guessing. The application service provider have chosen to avoid question and reply games and directly email assigned passwords to authorized people using their private and password protected email address. Yes the email is clear text encoded, but only the user will know what it is and what to do with it. | | 6. Do not permit the sign-in process to begin from an unencrypted web page and make sure that a new session is created by the session by destroying all prior sessions. | | 7. Ensure that the sign-off icon is always available on the top right of each dashboard - the user has no reason to close the web page when they can click the shut down icon. Users are not asked to confirm shutdown - they have pressed the icon so close everything down as fast as possible and say thank you. | | 8. Employ an automatic timeout period such as one hour of no activity to trigger an automatic sign off. Where the user has not been active for half and hour and the time of day exceeds the users end time of day sign in time, then they should be times out. | | 9. Everything is automatically written to the audit trail, but an exception is made to ensure that password data is not displayed to any user. Every field value change is automatically recorded in the database, but history has an exception to not display any password hashed value, even though that hashed value would be meaningless to any criminal. SHA encoding is undertaken before data is written tot the database, so deep inspection of the database would only show a set of encoded passwords, not the data that must be entered to sign in. | | 10. Do not permit a user to change their email address and then request a new password to be sent to that new email address. Only business email addresses that are assigned by the user"s manager are permitted. | | 11. No user can self-register and be sent their sign-in details. |
| | | 5.4.8 Insecure Cryptographic Data Storage | | Traditional web applications have failed to use cryptographic functions properly to protect data and user profiles. Criminals can exploit weakly protected data to conduct identity theft and credit card fraud. Every week, the security press have headlines of another major corporation that has had thousands of customer data records compromised. It is unprofessional to hold data without adequate encryption and it is not such a major cost issue. | | The application service provider began all those years ago with a professional approach towards encrypted and encoded data - even the development methodology involves cryptographic data dictionary information and encoded QMS data. |
ASP policies and rules include: | | 1. Only approved public cryptographic algorithms will be used. Each programmer is able to dream up their own clever tricks, but it is a legal obligation of the Internet application provider to be able to provide a set of cipher keys when requested by law enforcement - the only way to be certain that this obligation can be delivered is to ensure that home grown methods are not employed. | | 2. As string keys are employed, the certificates must be stored in a pair of physically secure locations that is not the same data centers as the servers. A benefit of having responsibility for a large number of certificates is that a fit and proper quality management system must be used to identify each certificate and associate with a particular machine. | | 3. Database passwords and message queue passwords are critical secure data that is stored in encrypted NAS devises and hidden among many terra-bytes of music and photographs. | | 4. No cardholder data is stored on any the application service provider servers, web application services are invoked to deliver PCI-DSS levels of security. |
| 5.4.9 Insecure Communications. | | Most web application fail to pay for an SLL certificate so network data is encrypted. It is easy to identify a traditional HTTP web site and a professional HTTPS application. | | The application service provider understand that HTTPS is essential to encrypt network traffic as a means to eliminate a large number of possible vulnerabilities. is a secure Internet application. |
ASP policies and rules include: | | 1. All private web traffic is encrypted by SSL, not just the sign-in procedure. All client, vessel and policy data is always encrypted within a temporary user session. | | 2. The green address bar introduced with Internet Explorer 7 has no real significance to business application users. The padlock symbol may look nice, but authorized users who use the same application day after day get no benefit from such decoration. | | 3. The Three-Tier-Architecture is implemented on a set of servers in the same physical rack that is in a secure location. Encryption between web server and application server and between application server and database server is not implemented as it would not deliver any business benefit. The predefined call interface between machines has been proven over that last decade to be fit for purpose in a business-to-business context. |
| 5.4.10 Failure to Restrict URL Access | | Many applications protect sensitive functions by preventing the display of links or URL data to unauthorized people. Criminal can use this weakness to access and perform unauthorized functions using URL data that the programmer though was secret. | | The application service provider employ an advanced URL architecture that ensures that programmers cannot leave the door open with URL manipulation. The design of every URL is according to exacting standards that shall not be violated. |
ASP policies and rules include: | | 1. No programs are on a web server that a criminal could discover and use. Brute force methods of file scanning may eventually show a folder contents, but any files in any folders are of no value to any criminal - they are images and CSS files that the criminal can download at any time. | | 2. No hidden or unpublished program names exist - ever. No administrators utilities exist that may be stumbled upon by a criminal. | | 3. No XML or XSL files exist to be reused to gain access to hidden secrets. | | 4. A very clear separation is made between client-side logic and server-side logic. It is accepted that client-side logic cannot be made private and it will be hacked, but all server-side logic is strictly hidden and cannot be seen any anybody. | | 5. Every program is activated by a record in the database, when the program is no longer supported, its database record is move to archive and that program cannot be executed from any other logic. A program can be switched off for a few hours where a problem is being investigated and the reinstated with simple changes to field values in the database. |
| 5.4.11 Buffer Overflow | | Certain programming languages can suffer from out of memory vulnerabilities. The application service provider have elected to employ information engineering fourth generation language technology that cannot suffer from buffer overflow and so the major cause of problems with windows-based applications is resolved at the architectural level. |
| 5.5 Vulnerability Testing | | The application is delivered by way of more than 1000 application services that work according to specification, are free of XSS and similar vulnerabilities, will not suffer a buffer overflow and cause a program stop and every function operates to the very highest levels of security, privacy and compliance. Where a more effective technique is discover and proven, then the whole of the application portfolio can be regenerated to deliver the application to that improved security standard. | | The application is only able to deliver application functions that match their documented data dictionary and functional specifications - where the specification of requirement is not complete and correct, then that function may not match its business requirement, but that cannot impact on its security standard in any way. | | The cost of testing for XSS attacks on each function could take six-months and by the time the last function had been tested, so many of the prior functions will have changed that XSS testing would have to start again. Badly managed projects can get into an endless testing cycle; can run out of budget or both. | | The application service provider resolve this issue in reverse, a single function is created and tested in every possible way to ensure that its overall architecture is beyond compromise. That proven architecture is then reused over and over again to engineer all other functions to the same exacting standard. Quality management ensures that during the production cycle, tiny changes in architecture are properly tested and the resulting application is a mirror of its parent function that is known to be complete and correct. |
| 5.6 Fourth Generation Languages | | Information engineering began in the 1980s with the creation of graphical and engineering methods to create provably correct software. A strong data orientated business development method is employed that begins with the complete application being expressed as records in the database. The data dictionary is not just an interesting document to read, but the internal access control mechanism that ensures that data entry conforms with permitted value and edit rules - the original documentation becomes part of the working application. | | Quality management has enabled construction methods to be refined to the point where it should be impossible for a defect to be created in any software. In the same way as a motor manufacture may refine their production line to eliminate manufacturing defects, the application service provider have refined their development procedures to the point where generated software should be complete and correct first time every time. |
|