So far, we've talked about computer security generally, but what is software security? The subject of this class, in particular software security, is a branch of computer security that focuses on the secure design and implementation of software. In other words, it focuses on avoiding software vulnerabilities flaws and bugs, while software security overlaps with and complements other areas of computer security. It is distinguished by its focus on a secure systems code. This focus makes it a white box approach where other approaches are more blackbox. They tend to ignore the software's internals why software Security's focus on the code important. The short answer is that software defects are often the root cause of security problems and software security aims to address these defects directly. Other forms of security tend to ignore the software and build up defenses around it, just like the walls of a castle. These defenses are important and work up to a point, but when software defects remain clever, attackers often find a way to bypass those walls will now consider a few standard methods for security enforcement and see how their blackbox nature presents limitations that software security techniques can address. Our first example is security enforcement by the operating system or OS when computer security was growing up as a field in the early 1970s, the operating system was the focus to the operating system. The code of a running program is not what is important. Instead, the OS cares about what the program does. That is its actions as it executes these actions called system calls include, reading or writing files sending Network packets and running new programs. The operating system enforces security policies that limit the scope of system calls. For example, the OS can ensure that Alice's programs cannot access Bob's files or that untrusted user programs cannot set up trusted services on standard network ports. The operating system security is critically important, but it is not always sufficient. In particular, some of the security relevant actions of a program are to fine-grain to be mediated as system calls, and so the software itself needs to be involved. For example, a database management system or DBMS is a server that manages data whose security policy is specific to an application that is using that data for an online store. For example, a database may contain security, sensitive account, information for customers and vendors alongside other records such as product descriptions, which are not security sensitive at all. It is up to the DBMS to implement security policies that control access to this data. Not the OS operating systems are also unable to enforce certain kinds of security policies. Operating systems typically act as an execution monitor which determines whether to allow or disallow a program action based on current execution context and the program's prior actions. However, there are some kinds of policies such as information flow policies that cannot be that simply cannot be enforced precisely without consideration of potential future actions or even non actions. Software level mechanisms can be brought to bear in these cases, perhaps in cooperation with the OS. We will consider information flow policies in more depth later in this class. Another popular sort of security enforcement mechanism is a network monitor like a firewall or intrusion detection system or IDs, a firewall generally works by blocking connections and packets. From entering the network, for example, a firewall may block all attempts to connect to a network servers except those listening on designated ports such as TCP port 80. The standard port for web servers firewalls are particularly useful when there are software running on the local network. That is only intended to be used by local users. An intrusion detection system provides more fine-grained control by examining the contents of network packets. Looking for suspicious patterns, for example, to exploit a vulnerable server. An attacker may send a carefully crafted input to that server as a network packet, an IDs can look for such packets and filter them out to prove the attack from taking place. Firewalls and IDS's are good at reducing the avenues for attack and preventing known vectors of attack, but both devices can be worked around. For example, most firewalls will allow traffic on port 80 because they assume it is benign web traffic, but there is no guarantee that port 80 only runs web servers. Even if that's usually the case. In fact, developers have invented soap, which stands for simple object: access protocol to work around firewall blocking on ports other than port 80, so permits more general-purpose message, exchanges, but encodes them using the web protocol. Now IDs patterns are more fine-grained and are more able to look at the details of what's going on than our firewalls, but IDS's can be fooled as well by inconsequential differences in attack patterns. Attempts to fill those gaps by using more sophisticated filters can slow down traffic and attackers can exploit such slowdowns by sending lots of problematic traffic, creating a denial of service, that is, a loss of availability, finally consider antivirus scanners: these are tools that examine the contents of Files, emails and other traffic on a host machine looking for signs of attack, these are quite similar to IDS's, but they operate on files and have less stringent performance requirements as a result, but they too can often be bypassed by making small changes to attack vectors. Now Discover More conclude our comparison of software security to black box security. With an example, the heartbleed bug, heartbleed, is the name given to a bug. In version 1.0 point one of the open, ssl implementation of the transport layer, security protocol or TLS. This bug can be exploited to get the buggy server running open, ssl to return portions of its memory. The bug is an example of a buffer overflow, which we will consider in detail later in this course. Let'S look at blackbox security mechanisms and how they fare against heartbleed operating system enforcement and antivirus scanners can do little to help for the former. An exploit that steals data does so using the privileges normally granted to a TLS enabled server. So the OS can see nothing wrong for the latter. The exploit occurs while the TLS server is executing. Therefore, leaving no obvious traces in the file system. Basic packet filters used by IDS's can look for signs of exploit packets. The FBI issued signatures for the snort IDs. Soon after heartbleed was announced, these signatures should work against basic exploits, but exploits may be able to apply variations in packet format such as chunking to bypass the signatures. In any case, the ramifications of a successful attack are not easily determined, because any exfiltrated data will go back on the encrypted Channel now. Compared to these software, security methods would aim to go straight to the source of the problem by preventing or more completely mitigating the defect in the software