Software Development for Cyber Security

Many years ago I went to school for a Computer Science degree before switching to a Computer Engineering degree. During that time, we learned many of the tricks of the trade on how to speed up programming efforts including using online repositories for commonly used code. Years later as a Computer Scientist for the FBI, I often used snippets of online code to speed up my Python scripting. We were cautioned to make sure we knew how that code functioned in case we ever had to testify in court about the script and how we acquired the final data that was used in prosecution. I always considered myself an intermediate programmer at best and was often in awe of the more seasoned programmers I worked with and they all introduced me to online repositories for common code snippets in various languages. When this news was revealed that one of these common repositories may have been hacked ahead of the Solar Winds breach, it caused quite a stir among my programmer friends. Many of them had used code from their common site and concerns were raised as to whether their code had vulnerabilities “baked in.”

This concern is valid but it also raises a much larger issue for all software developers in Cyber Security. Even such ubiquitous software utilities such as GitHub have had a number of vulnerabilities identified in software housed there. CISA publishes alerts that often affect these repositories. (See here) and GitHub now has ways to notify users of security vulnerabilities. What about other open source software? How many other known (and unknown) vulnerabilities will turn up in 2021 and beyond? It definitely increases the difficulty of securely developing software as we move forward. Or maybe we are expecting too much from our developers? Maybe security is a multi-layered system with programmers doing their due diligence to secure their product with other security products monitoring the software to ensure it is acting as intended.

This is where so many companies will start talking about Zero Trust and how to implement it. I heard a fellow security technologist declare that he would not use the words “Zero Trust” anymore because it had become a buzz word with little meaning kind of like “Cloud” and “Hybrid”. I like that declaration – what I would suggest at this point for our software developers is security tied to what their software is supposed to do – behavioral security. Security that knows that the software should do and when it tries to do more than its “normal” behavior, it gets blocked until a security review can be instituted. Some would say this is Zero Trust or Behavioral Analytics, I would concur that the latter is closer to the truth. No software should be trusted completely. Neither should any user or service on our enterprises. All should be compared to a baseline performance model and allowed to proceed only when this comparison is declared legitimate. Software is part of our supply chain whether development is done internally or outsourced. Supply chain security is something we all must start recognizing as a potential threat and appropriate counter measures should be implemented.