Last week, the Securities Industry and Financial Markets Association (SIFMA) ran Quantum Dawn IV to test the resiliency and response of the financial services industry to a major cyber incident. Today, a new CAST report on application security health (CRASH) highlights that finance has some of the worst code — in security terms — of all the major industry sectors.
The details come from the CAST Software CRASH Report on Application Security (PDF). CAST analyzed 278 million lines of code from 1,388 applications and found 1.3 million CWE (MITRE’s Common Weakness Enumeration) weaknesses in code developed under .NET and Java EE. The implication is that the banking sector will need to take considerable care in the implementation of Europe’s open banking regulation (PSD2) due to come into force in January 2018. It will need to ensure that third-parties do not implement insecure code with access to banking code that already has a higher than average density of its own coding flaws.
CAST specifically analyzed code developed across ten different industry sectors within .NET and Java EE environments. It found a significantly different density of CWEs between the two environments, with .NET code generally having a greater density of weaknesses than Java EE — in some cases with more than 35 CWE weaknesses per KLOC (1000 lines of code). A CWE is a coding weakness that could potentially be exploited by an attacker — such as a buffer overflow flaw, or a SQLi or cross-site scripting flaw.
Financial services, Telecom and IT Consulting had the highest mean CWE densities. Energy and Utilities had the lowest CWE densities.
CAST also noted a difference between Waterfall coding and Agile coding — with agile coding tending to introduce fewer weaknesses.
CAST’s chief scientist, Bill Curtis, told SecurityWeek that while the Waterfall approach of defining and designing the entire project upfront is theoretically a good idea, business pressures — with senior management requiring amendments in progress — often make its actual implementation less than perfect. This in turn leads to additional work requirements and rushed deadlines introducing additional weaknesses.
In general, there are fewer CWE weaknesses found in Java EE developments that use an agile approach to development; that is, building the project while still in development, adding new features as required by senior management, and releasing new versions as soon as they are ready. This can be taken too far — a high number releases (more than 6 per year) tends to introduce a higher number of weaknesses. This could be indicative of business seeking new features and rapid releases above secure coding. Security neds to be built into the process rather than added on to the application.
Nevertheless, there is still a surprisingly high density of weaknesses found in all applications across all industry sectors. Curtis would personally recommend a hybrid approach: using a waterfall approach to get the architecture right from the beginning, but an agile approach to delivering code.
He sees the real problem as a lack of discipline in coding that is itself the result of a lack of adequately qualified programmers. The rush to digitizing all aspects of business has placed a severe strain on the available supply of programmers — schools and colleges simply cannot produce new programmers as fast as necessary. Furthermore, the coders that are provided tend not to have any formal training in ‘secure coding’.
The under-supply of programmers has led to the development of the off-shore programming industry — and especially from India. CAST’s analysis shows no real difference in the number of CWEs between on-shore and off-shore coding. However, Curtis told SecurityWeek that the continuing growth of demand has already absorbed the top layer of programmers from the off-shore industry, and less able programmers are beginning to be employed.
He does not, however, believe that the growth in demand will inevitably lead to increasing security weaknesses in the code. Companies will always need to select the best programmers they can find to employ, but now need to provide additional in-house training for secure coding. This approach coupled with automated static code analysis would improve the quality of new applications — and help strengthen the security of existing applications.
In the meantime, he believes that school education needs to change. At the moment it concentrates on teaching youngsters reading, writing and arithmetic. He believes that basic coding should be given similar emphasis to reading and writing. In the future, schools may need to discuss elegant routines in the same way as they currently discuss Shakespearean metaphors.
