Threats and Vulnerabilities

Introduction
Note: There’s a covert channel in this lecture. Can you find it before it is revealed?

Iatrogenic Software Security Problems
Iatrogenic is a great word except for the fact that it really applies only in a medical context: harm caused by the physician’s treatment.
Here's an example: a patient goes into the hospital with a broken leg and gets an infection from being in a contaminated hospital environment; it’s called an iatrogenic infection and it was caused by the treatment. Given the medical terminology used for malware, such as viruses, it seems reasonable to consider a program made vulnerable by a coding flaw and victimized by a virus as having an iatrogenic infection.
Vendors take it as a fact of life that they can expect a certain number of bugs for a certain number of lines of code. Having 10 bugs per 1,000 lines of code is considered common. It does seem strange that, with all our digital expertise, we still can’t expect consistently accurate code.
One of the most successful attacks, the buffer overflow, is based on the failure of developers to properly constrain the assignment of memory. This is not meant to imply that it is all the fault of developers. The resources required to eliminate this problem make the task formidable.
However, much of the fault with software security is the result of a hasty development cycle, as mentioned above.
Although it is considerably more difficult to correct coding problems after an application is complete, the trend is to work quickly (to maintain market share) and then patch problems as they surface. To date, this has been acceptable to customers. There is little will to fight the battle to make software vendors liable for damage caused by programming errors. If software vendors were as liable for flaws as automobile makers are, it would be a very different story.

Software Vulnerabilities
One benefit of ubiquitous global communication is that information about vulnerabilities can be shared as they are discovered. Bugtraq is an excellent example. The website, maintained by
SecurityFocus, is a very well‐respected source in the InfoSec community for information on the latest software vulnerabilities. However, rapid communication is not always enough to protect corporate networks, not to mention individual users. Depending on how a particular vulnerability is discovered, the person or team who identifies the flaw may be hesitant to reveal

it to the vendor for fear of legal reprisal. The prosecution of those who access remote systems is getting easier as the laws get tougher. Even when there do not appear to be legal obstacles, there can be trouble. It has long been the contention of many hackers that vendors do not want to spend time and money on patching existing systems and programs. They would rather use their resources for the development of new products. Many feel that it is only when confronted with the possibility of public exposure that they act. Clearly, the ethical thing for hackers
(meaning ethical experimenters, not malicious crackers) to do when they discover a vulnerability is to notify the vendor. The disagreement arises when the hacker thinks the vendor is not acting fast enough. How much time should a vendor have in order to produce a security patch? Hackers feel that a matter of a few weeks is usually adequate, and they become frustrated when vendors hesitate to act for months. Hackers point to the risk that many companies and individuals are unknowingly exposed while vulnerability remains unpatched, and thus, discoverable by crackers.
CISCOGATE
This tension between security investigators and vendors was dramatically demonstrated in
2005 when a researcher with Internet Security Systems got so frustrated with months of inaction by Cisco after his company had informed them of a buffer overflow exploit in their routers that he finally demonstrated the attack at a Black Hat convention, hoping to force Cisco to act. Just before making the presentation, the researcher resigned from Internet Security
Systems in order to protect them from legal action. Instead, both Cisco and Internet Security
Systems took action against the researcher, preventing any further dissemination of information about the bug. Cisco did, however, act quickly to address the flaw.
Technical attacks on computer systems that achieve administrative control of the target computer are almost always based on the exploitation of a software flaw. Can programming flaws be eliminated or even substantially reduced? There are a number of approaches to combating programming flaws, such as enforcing secure development policies and operational assurance procedures to test, maintain, and review software usage; but the devilish detail – metrics – raises its insidious head. How do you measure security, interoperability, recoverability, and other important qualities?

External Software Security Problems
Although exploitation of software flaws is a big problem, so, too, are malware and other types of software attacks. A virus, code that is attached to a program and that replicates itself, and a worm, malware that spreads copies of itself throughout networks, are both examples of common attacks. The fact is that malicious, or foolish, people can write and distribute harmful software. Even those who do know how to write code can cause a lot of trouble. Script

kiddies are unskilled crackers who use automated programs created by others to spread mischief. Many tools that can be used for scanning networks, testing for vulnerabilities, exploiting vulnerabilities, and delivering payloads are readily available on the Internet for free. Keystroke loggers have had great commercial success; parents can use them to monitor their children’s Internet activity. One of the most interesting software attacks is the use of a covert channel. A covert channel is designed to send confidential information along with innocent‐appearing data. For example, if you go back to the heading in this lecture called
Iatrogenic Software Security Problems, and took the first letter of every sentence that contains within it a punctuation mark other than a comma or an apostrophe, you could reconstruct my naughty message which is carried in an innocent‐looking couple of paragraphs. Software vulnerabilities are probably the most serious in all of information technology. It’s probably easier to protect the person of the president than it is to protect his itinerary.

Solutions and Confusion
One of the main thrusts of the industry’s efforts to secure software is developing and, perhaps more importantly, enforcing software assurance policies during development and implementation. Policies are general statements that describe required outcomes. Procedures provide the step‐by‐step methods of implementing policy. Even in a mid‐sized company, the time, money, and downright pain associated with the development of a complete and appropriate security policy are immense, and that’s not even considering implementation and enforcement. In order for security policies to be optimally effective, there must be tremendous corporate will, and the reality is that most business organizations lack this will. For some companies, it is relatively painless to create and enforce physical security policies, authentication policies, and other macro‐policies that are easy to audit; but when it comes to enforcing less controllable policies such as complete, parallel, third‐party assurance testing during the coding stage of software development, or consistent intrusion detection response procedures, there may not be sufficient will to overcome the scarceness in personnel, funding, and time. Even when not created as optimally as might be desired, however, a well‐designed and realistic security policy and procedure program can lower an organization’s exposure to risk significantly. In the risk analysis process, assets must be identified and prioritized. It is critically important to understand which business processes are supported by which assets. Some servers will have a higher priority than others based on the business processes they support. At the same time, not all business processes are equal. Business processes that are mission‐critical will have a higher priority than others. This is why it is so important to have IT leaders and managers who are knowledgeable about business priorities. Yes, information technology departments have priorities too, but when it comes to prioritizing policy development, capital expenses,

scheduling, and many other elements of management, business objectives always outweigh IT convenience. The all‐too‐common separation between IT workers and upper‐level management when it comes to information security is an artificial one. Without revenue and without profit, there is nothing to argue about. IT managers need to speak the language of business and understand that, despite the attraction of new technologies and the doomsday disciples
(security vendors), a good, sound risk analysis will answer many questions regarding the need for security controls. It’s not an easy process; it’s very hard to put a value on intangibles, but it can be done. Insurance companies do it all the time.
Today, most business organizations have become completely dependent on digital information storage and communications. The consequences of violating the trust and privacy of clients, business partners, and employees – not to mention the growing number of state and federal regulatory mandates – are potentially catastrophic to the point of threatening the organization’s existence. Meeting the legal and ethical expectations of due diligence in the management of information is an ongoing responsibility, but these responsibilities and challenges can be met dispassionately and logically. This is the ongoing task for managers in information technology and for managers in production and service.

Something to Think About
How can you tell how much exposure to risk you can tolerate? Sure, you can crunch some numbers and come up with the likelihood that something bad will happen, the cost to your company if it does happen, and the cost to implement a control that will decrease the likelihood that the catastrophe will cause damage, but on what do you base your decision whether to implement the control or not? Is it easier to decide based on the cost of the control or on the cost of the potential damage? Which type of event is hardest to assess – the server going down or the building going flat in an earthquake? If you were on the board of directors, how would you determine the degree of accountability when assessing managements' actions or lack of action before a catastrophe?