Since a good portion of this course has focused on the importance of security in our software and other applications that we develop in the overall process of the life cycle of the CPU and other components, this section is more focused on why is software so inherently unsecured, in the first place. The principles with the requirements, basic tenets of secure architecture and design, design and development, and actual coding with the architecture of the CPU are all about how to develop applications, systems and such but doing so with security in mind. So, this section is over why is our software so unsecured?
In an earlier module, there was a question of how many students already had taken some introduction to programming course like in high school and many people could say that they had the experience. In that experience, many had shared that there wasn’t any emphasis on security as part of the programming. Rather, it would be a patch or a fix later on after the functionality was programmed. So, in terms of historical or traditional methods of teaching, the security code generally comes much later. So, programmers haven’t necessarily been taught to think in terms of security as they are making their application. So, as new people are being trained today, we have to incorporate these basic security principles, as an integrated piece of code rather than as patches later on.
In terms of why our software is unsecure, we can look at a specific example of the TCP/ IP in terms of internet protocol. In the United States, we are currently using version 4. However, many other countries are using version 6. There’s been mention of the move towards the version 6 for the past 20 years, in the United States. It’s a little like the metric system in the states. In that, pretty much every other country is using metrics except for the United States. So, the version 6 has a different set of parameters . Rather than having it in alpha and numeric sort of organization, it is a hexadecimal type of organization and is different from what folks in the US have been using traditionally.
So, there’s a lot of feet dragging on the internet protocol upgrades, here. There was a little flurry of activity when at one point we were running out of IP addresses. So, there was a driving force at one point, so as to step up the transition to version 6. However, it was discovered to use network address translation.Network address translation is where there is one external IP address and then several like 500 maybe, which are internal. So, instead of each person having their own external access, and then using up all those addresses, then the 500 are only using one. So, that impetus for creating new IP addresses ie., faster transitioning to the version 6 for a greater number of addresses for people to use, ended up being unnecessary. Therefore, the original driving force then lagged and so the United States still doesn’t have the version 6 of internet protocol.
Many folks are perfectly fine with version 4 also because it wasn’t originally designed to need security in that protocol as it was originally designed for the military and governmental installations to utilize. Since it was already a fairly secure link, there wasn’t any real drive toward internet protocol security. However, this version has outgrown its original environment and much like other programs where they are being used in other environments than their original design purpose, has issues in the new given situation or environment.
So, the original design was for military and so was an already secure environment then expanded to the whole of the internet, which is not a secure place at all. So, we’ve got to go back and fix as patches or other sort of “hot fixes” the security level, rather than having the security coding already integrated in. Anytime we have to go back to fixing something rather than having it right the first time, is going to take extra effort and energy. Also, it generally doesn’t run nearly as well as when the security is already integrated within the program.
Other problems as to why our software is often unsecure is because of a lack of funding. For example, we may end up going overbudget in producing the application, but we end up not getting any more resource from the client and so we quickly finish it up without having the security component as a part of the main functionality of the program. Another example of issues as to why it may not be as secure of software is because of trying to meet deadlines.. If you’ve promised the client the application will be done by a certain date, then it needs to be completed by that date.
It may be possible that you’ve run out of time to include the security protocol. We think we’ll add it later. Security is just not high enough priority to create it as an integrated concept. Although it’s easy to blame the developers, it’s not always up to them because of the project manager meetings in the original gathering of requirements as to what the client wants. Fairly often, security isn’t really brought up. However, it is an essential component especially if we are staying in the version 4 format of internet protocol. The unsecure code can lead to high costs because of the data compromise and certainly the vulnerabilities, threats and attacks of those out there in the big bad world of the ugly insecure internet.
There are several issues which can lead to an unsecurely written code via unsecure software. There’s the traditional, historic lack of emphasis in classroom situations and new people are being trained for programming. There’s the fact that the United States is still using version 4 of internet protocol (TCP/ IP) as opposed to other countries’ use of the much more secure version 6. There can be a limit to funding, time, resource or even a lack of limit of communication between the project managers and the developers. In any regards, there are all kinds of reasons behind why our software is so unsecure.