Alice and Bob Learn Application Security. Tanya Janca

Читать онлайн книгу.

Alice and Bob Learn Application Security - Tanya Janca


Скачать книгу
employee not reporting a vulnerability to management in order to avoid the work of fixing it (potentially all three, depending upon the type of vulnerability)

       Here are some examples of accidental threats and the parts of the CIA Triad they affect:

       Employees using software improperly, causing it to fall into an unknown state (potentially all three)

       An employee accidentally deleting valuable data, files, or even entire systems (availability)

       An employee accidentally misconfiguring software, the network, or other software in a way that introduces security vulnerabilities (potentially all three)

       An inexperienced employee pointing a web proxy/dynamic application security testing (DAST) tool at one of your internal applications, crashing the application (availability) or polluting your database (integrity)We will cover how to avoid this in later chapters to ensure all of your security testing is performed safely.

       WARNING Web proxy software and/or DAST tools are generally forbidden on professional work networks. Also known as “web app scanners,” web proxies are hacker tools and can cause great damage. Never point a web app scanner at a website or application and perform active scanning or other interactive testing without permission. It must be written permission, from someone with the authority to give the permission. Using a DAST tool to interact with a site on the internet (without permission) is a criminal act in many countries. Be careful, and when in doubt, always ask before you start.

      “Layers” of security can be processes (checking someone’s ID before giving them their mail, having to pass security testing before software can be released), physical, software, or hardware systems (a lock on a door, a network firewall, hardware encryption), built-in design choices (writing separate functions for code that handles more sensitive tasks in an application, ensuring everyone in a building must enter through one door), and so on.

Schematic illustration of the three layers of security for an application and an example of defense in depth.

       When creating software: Having security requirements, performing threat modeling, ensuring you use secure design concepts, ensuring you use secure coding tactics, security testing, testing in multiple ways with multiple tools, etc. Each one presents another form of defense, making your application more secure.

       Network security: Turning on monitoring, having a SIEM (Security information and event management, a dashboard for viewing potential security events, in real time), having IPS/IDS (Intrusion prevention/detection system, tools to find and stop intruders on your network), firewalls, and so much more. Each new item adds to your defenses.

       Physical security: Locks, barbed wire, fences, gates, video cameras, security guards, guard dogs, motion sensors, alarms, etc.

      Quite often the most difficult thing when advocating for security is convincing someone that one defense is not enough. Use the value of what you are protecting (reputation, monetary value, national security, etc.) when making these decisions. While it makes little business sense to spend one million dollars protecting something with a value of one thousand dollars, the examples our industry sees the most often are usually reversed.

       NOTE Threat modeling: Identifying threats to your applications and creating plans for mitigation. More on this in Chapter 3.

       SIEM system: Monitoring for your network and applications, a dashboard of potential problems.

       Intrusion prevention/detection system (IPS/IDS): Software installed on a network with the intention of detecting and/or preventing network attacks.

      Giving users exactly how much access and control they need to do their jobs, but nothing more, is the concept of least privilege. The reasoning behind least privilege is that if someone were able to take over your account(s), they wouldn’t get very far. If you are a software developer with access to your code and read/write access to the single database that you are working on, that means if someone were able to take over your account they would only be able to access that one database, your code, your email, and whatever else you have access to. However, if you were the database owner on all of the databases, the intruder could potentially wipe out everything. Although it may be unpleasant to give up your superpowers on your desktop, network, or other systems, you are reducing the risk to those systems significantly by doing so.

      Examples of least privilege:

       Needing extra security approvals to have access to a lab or area of your building with a higher level of security.

       Not having administrator privileges on your desktop at work.

       Having read-only access to all of your team’s code and write access to your projects, but not having access to other teams’ code repositories.

       Creating a service account for your application to access its database and only giving it read/write access, not database owner (DBO). If the application only requires read access, only give it what it requires to function properly. A service account with only read access to a database cannot be used to alter or delete any of the data, even if it could be used to steal a copy of the data. This reduces the risk greatly.

       NOTE Software developers and system administrators are attractive targets for most malicious actors, as they have the most privileges. By giving up some of your privileges you will be protecting your organization more than you may realize, and you will earn the respect of the security team at the same time.


Скачать книгу