National Cyber Security Awareness Month – Some Things to Think About

It doesn’t take much convincing to get IT people – and developers – to think about cyber security. However, just in case, the US Department of Homeland Security has declared October “Cyber Security Awareness Month.” While the event’s focus is very broad – from consumers and even children on up, this year a specific element of the event is building security into information technology products, including the phones, tablets, and computers.

There is no doubt data, especially sensitive data, must be better protected, whether in the cloud, in a local data-center, or traveling anywhere in between. The philosophies of data protection have continued to evolve with the threat. One significant trend is the recognition that no network or system can be made 100 percent secure. Therefore, the focus has shifted to making the data itself more secure, and finding that level of protection best suited to the sensitivity of the particular application and its data. Consider that certain 128-bit encryption mechanisms, including some typically used by e-commerce websites, are now considered vulnerable. A much better choice is the Advanced Encryption Standard (AES-256), a 256-bit specification for encryption established by the U.S. National Institute of Standards and Technology (NIST) in 2001.

However, threats are not standing still. NIST estimates that 1024-bit SSL will be cracked before the end of this decade and 2048-bit SSL on or before 2030.

Progress applications offer SSL/TLS (2048-bit) wrapped web transmissions, and military-strength (AES-256) encryption within product databases, to guard data both on the move and upon arrival at its destination.

A related concern stems from laws and regulation intended to safeguard data. For instance, some jurisdictions require that certain data stay within that region (European Union within Europe, Middle East within Middle East, etc.). Unfortunately, in this day and age of “process-anywhere” cloud computing, organizations could have difficulty certifying to a forensic investigation where and how their data has been protected.

Progress has met these risks head-on; our application frameworks can be built, moved, and rebuilt anywhere, literally within hours, our infrastructural safeguards (including anti-malware defense and host-local forensics) move with the app-server(s) in question, and we are incorporating meta-tagging functionality to flag individual data/objects as “Confidential,” “Protected Health Info,” or, for example, “Stay Within EU Region Only.”

Too often we see vendors and developers slapping a final “security module” or “security appliance” on after-the-fact. True security is incorporated at product design time, during subsequent spirals and peer review, and during end-to-end quality and acceptance testing. In this sense, “security requirements” should be no different from “color-blindness accessibility requirements” or “webpage-response-time requirements” – incorporated at the very beginning, considered and evaluated during each design increment, and verified via testing.

Truly, security must be ‘baked in,’ not ‘bolted on.’