• United States




Enhanced Internet architecture to address WannaCry

Jun 01, 20173 mins
Application SecurityCloud SecurityInternet

Global Internet attacks take advantage of current systemic vulnerabilities. An enhanced architecture with improved web applications can help protect the Internet and its critical global applications.

internet of things graphic
Credit: Thinkstock

After understanding the various InfoSec vulnerabilities that many companies have, here is a wish list of items that could address global attacks like WannaCry. How do companies fend off global attacks; they create a better global Internet architecture. An upgrade to infrastructure products, internet protocol changes, and an improved software design of IT solutions would all be helpful in addressing global attacks.

First, the infrastructure used by an application should be accessible via APIs. This should be like SDN (Software Defined Networking) for applications. SDN controls CPU cycles, network bandwidth, and storage type and allocation.  Each application could access a software development framework containing expanded APIs so that it enables reading from and writing to infrastructure components. New application level components would also be included in Java/C#/C++ and other frameworks. This framework enables the protection of the application to be more seamless – no gap between the infrastructure components and the applications they support. Using APIs to request infrastructure resources may also lead to changes in how the resources operate.

 The HTTP and HTTPS layer 7 protocols could be beefed up to deal with DDoS and other OSI layer 7 attacks.  It would be beneficial to have this protocol layer improved to address some security weaknesses while still being backwards compatible  The backward compatibility would still support existing HTTP and HTTPS sessions.  The updated protocols would have some hooks that enable them to be state driven which would be harder to attack than the current stateless model that exist today.  It reminds me of when the 8086 processor and the applications that ran on it were still supported by the newer 80286 processor. The processor was backwards compatible.  We need the protocol upgrade to be backwards compatible.

There is a need for security solutions that are meshed in their interaction with one another.  There are too many point solutions in the products that are offered today. Making newer security solutions that are API accessible moves the burden for security from DevOps personnel to the application itself. It would be better to have all functions supported within the application rather than in the DevOps realm. It is possible that new products would be created like a switch router that has firewall functions built into it also. This would require quite a bit of brainstorming to come up with new products that lock down the data centers or clouds because they perform multiple functions.

Before the APIs for infrastructure systems exist, there is another important DevOps function.  It involves centralization of configurations of systems so that an automated restore can occur if something goes wrong with an application or a portion of the infrastructure. The ability to roll-back to a stable architecture and implementation is critical. The configuration repository keeps all of the information technology systems in a NTP (Network Time Protocol) timeline which enables the rightly timed rollback of the infrastructure and the applications it supports.

Creating new infrastructure APIs within frameworks, improving protocols while making them backward compatible, developing new meshed security products and centralizing the collection of security system parameterization all involve a great deal of work. But, the Internet is a global tool that needs a more sophisticated design to address global attacks. All kinds of critical functions are being integrated into and on top of its clouds. It must operate in all situations.


Greg Machler is a Technical Lead that focuses on management of technical issues related to IT security project deployments. He has interacted with many different types security project experts. He enjoys clearly defining problems so that they be resolved by a variety of experts.

The opinions expressed in this blog are those of Gregory Machler and do not necessarily represent those of IDG Communications, Inc., its parent, subsidiary or affiliated companies.