Banks provide information about account balances, allow money to be transferred or withdraw, need trust and confidentiality as the foundation of their business, and provide interfaces to their transactional systems. They have always been the focus of criminal activities. Technical progress and optimized processes have not changed that fact, but have instead opened up new rounds in the competition between good and evil.
Current Attack Scenarios
Recent headlines describe the current state of affairs.
“Access via USB stick 000507607999: Check whether a cash machine has been hacked” was an article in Focus money online on 9.1.2014. The article refers to malware installed by criminals onto cash machines with a USB stick that allows money to be withdrawn directly via the withdrawal module. The malware even has its own security features, allowing cash to be dispensed only after entering a certain number. In attack scenarios, the number is sent to the perpetrators by mobile phone.
“Instructions for perfidious attacks via USB go public” is the title of a Zeit online article from 8.10.2014. The article describes a type of attack performed using manipulated USB controller software. The malware exists in several versions and is often referred to as BAD-USB. It can manipulate almost any USB device as another device and thus be used to launch an attack. Even supposedly harmless devices can be forced to run malicious software that performs unexpected processes.
The New Threat Levels
The concrete possibilities of attack and potential threats are example of an entirely new level of threat. The perpetrators are skilled, that is clear. The malware looks professional and is available in multiple languages and versions. The perpetrators are well-organised, dividing their tasks in a coordinated manner.
They have very cleverly taken advantage of business and technology trends that are currently dominating financial sector and IT business, where standardisation is on the rise at all levels. Cash machines are increasingly being made with standard components instead of proprietary parts. They run standard operating systems and standards such as XFS are now available for self-service applications.
In this digital age, information can be lifted with just a few clicks. With a little research and basic knowledge, it’s easy to acquire the skills key to successful criminal activity. The on-going movement towards a division of labour with the use of outsourcing and temporary workers in the world of business and the use of frameworks and IT operated by third parties offers up plenty of new avenues for attack scenarios.
Countermeasures in the Software Development Process
If those sectors don’t want to give up the benefits associated with these trends, then they face the challenge of treating security as a key criterion for quality and thus a factor determining the success in all development phases and across all processes.
Therefore it is necessary to develop safe and secure software that can then also be operated in secure environments. From the perspective of software vendors, effort is needed in all phases of the classic waterfall model. We consider this both exemplary and a simplifications, although the basic statements apply equally to all process models.
Security requirements originate from a very wide range of different sources. Depending on the application, there can be relevant regulatory or statutory requirements or industry regulations such as PCI-DSS. Security requirements are often not functional; they often exist rather as vague implicit assumptions. Accordingly, it can be difficult to formulate and document them in a practical manner, but considering security in requirements management is the underlying foundation for the activities that follow and therefore critical to the overall success.
One security-specific measure is threat assessment, usually done after the essential security requirements have been identified. Threat assessment consists of the following steps:
- Identifying the assets: first, the company assets requiring protection are identified. This is an important prerequisite to evaluation and risk assessment.
- Designing an architecture: in the second step, a rough architectural design is created to provide an overview that serves to create and describe confidence limits.
- Breaking down the application: in this step, application components requiring separate examination in detail are identified.
- Identifying and assessing threats: the threats are then modelled based on the previous analysis. The assessment then results in the requirements for the final phase.
- Planning action: finally, appropriate measures are formulated and planned. This should support a plausible balance of risks and costs.
In software design, we are familiar with the principles that form the basis for secure designs. Examples include: defence-in-depth (the castle approach), fail-safe defaults, minimize attack surfaces, fail securely, run with least privilege, don’t trust infrastructure, and establish secure defaults. Omissions in this phase can be corrected later only with great effort.
These principles are implemented in our programming. Proven measures such as input validation and output encoding prevent the success of more common attack techniques such as code injection and cross-site scripting (XSS). Both techniques have been on the OWASP (Open Web Application Security Project) Top-10 list for years.
The test phase checks the implementation of these security requirements in the context of the overall requirements, usually in special test environments. Special security checks include so-called penetration tests that take place in the production environment to validate statements about the level of security across productive systems. The basic idea behind this type of test is to assume the attacker’s perspective and proceed creatively and also unconventionally. Thus, most penetration tests are more like black-box tests. The attackers are usually not familiar with internal or development documents. Over time, however, white-box tests have also developed, where the test team is given insight into the documentation as part of the penetration test. This increases the quality of the attacks and thus the validity of the results. With insider attacks resulting from social engineering or the use of well-documented foreign components, it can also be assumed that perpetrators can also acquire internal knowledge and that not all of the knowledge required can actually be kept secret.
During the software setup and operation phases, other measures can also be taken to make the use of the software more secure. These include hardening measures in hardware and software, such as removing unused components, deleting standard users or changing default passwords, as well as the secure design and testing of software services and operating processes.
Countermeasures in infrastructure and production:
Even software developed in a secure environment can be attacked. In a threat assessment, risks are often identified that require measures to be taken in the productive environment to protect the software from modifications and manipulation. Attack paths are system interfaces and network infrastructure. Possible countermeasures include:
- Physical security: these measures restrict physical access to the system and make such attacks more difficult.
- Access control software: so-called whitelisting solutions identify unwanted features and views by checking against a list of allowed and desired functions and preventing the execution of unwanted features. This approach also successfully wards off attacks for which details are not known beforehand. Often, control options can be integrated for USB devices and the like.
- Hard-drive encryption: making re-engineering attacks more difficult with encryption that enhances the protection afforded by whitelisting and access control options. If whitelisting protects the drive against attacks while in operation, encryption provides protection when it’s not, thus expanding the extent of protection.
- Self-service specific defences: special solutions often implemented in hardware that protect against skimmers. Skimming is spying on PINs and passwords.
General Security Measures
Defence can also be organised at the payment system and card scheme levels. A good example of this approach is the increasing use of chip technology. This is replacing magnetic-strip cards more and more. Chips are clearly much more difficult to duplicate than magnetic strips. The resulting higher effort required for skimming to succeed is leading to a stagnation in this type of attack.
Analogous to the concept of secure standards, banks area also increasing their efforts to expanding availability at the express wish of their customers. Bank cards that the customer specifically authorises for use in certain countries or customer-specific limits are good examples of this approach.
Security Services at S&N:
S&N AG believes security is an important quality criterion in software development. Our certified team members focus on this priority in projects for our customers. The range includes many aspects from identifying security requirements and preparing threat assessments to software development and penetration testing. The selection and specification of security systems and their subsequent customisation and operation are our focus. The integration in IT development and operational processes ensures synergies and reduces expenses. Take advantage of the experience and expertise at S&N AG as another building block in the success of your business.