Security by obscurity

Back in the day, the author used to hardcode connection strings for dev, QA, and prod environments so she could switch them when testing. She had no idea the security problems she caused as a dev so many years ago.

No, it is not. Captchas are very difficult for people who are visually disabled to use, and even for fully abled people at times. They are annoying and bothersome as well; users detest them.

The password manager called 1Password can also be used as an MFA authenticator, meaning it will generate that code you get and need to enter into a site as an MFA challenge. It automatically copies it to your clipboard as soon as you have entered your username and password, so you can paste it directly in. After you've pasted it and have logged in to the site successfully, it replaces what was previously on the clipboard, in case you needed it. That is usable security. They are trying (and in the author's opinion succeeding) to make MFA challenges less time consuming, less unpleasant, and less error prone. It's still very secure, but much easier for the user.

Data in the URL parameters can easily be changed by the user and is therefore not trustworthy. If the user happens to be in a public café, and your website is not available over HTTPS, an attacker could easily change the parameters in an MITM attack (Man-In-The-Middle or Manipulator-In-The-Middle). There are many other situations that could lead to those inputs being changed, maliciously or even accidentally, that could cause those values to be dangerous to your application. Always validate all input.

Confidentiality. They will most certainly have violated their terms of employment, any non-disclosure documents they have signed, and very likely the law.

Integrity, because the data is still available, and the data may still have remained confidential (and likely the setting was not considered a secret), but changing the setting to an incorrect/damaging setting breaks the pillar of Integrity.

Availability, because your heat is not available to you. Hopefully you don't live in Ottawa, Canada, and if you do, that it's not February!

Yes, this is an insider threat. Practical jokes that happen inside your company and only affect those who work there can be fun and playful. Unapproved features or “surprise” functionality is a security team's worst nightmare.

You can ensure you only visit websites via HTTPS, so that your traffic is encrypted. You can use a VPN (virtual private network), which creates a “tunnel” to either a safe network or your work network (usually). You can install antivirus or antimalware on your machine. You could decide to just use your cellular data instead, if you feel the network you are joining may be particularly dangerous (for instance, if the café was in Las Vegas during Def Con).

No. The key identifies you as someone who lives at the apartment, but not which one of you it is. Authentication needs to identify an individual, not a member of a group.

1) Password resets for users cannot be done more than one time in a 24-hour period.

2) Each API must connect using its own service account; they cannot share.

1) If brakes, airbag, or any engine functionality has been tampered with, send an alert to the user and their designated garage immediately. Do not allow the car to drive until an authorized mechanic has issued an override command.

2) Each driver of the car must have their own key to identify them, plus another factor of authentication (specifically a thumb print) in order to start the car. All other potential drivers are rejected.

1) Toaster cannot go over X degrees in temperature, if so, issue an alert and issue a shutdown override.

2) Toaster admin module requires a second factor of authentication in order to override temperature settings to above manufacturer's recommended guidance.

1) Application must be PCI (Payment Card Industry) compliant.

2) The database that contains the credit card information must be labeled “confidential,” only one service account (the application's) can access it, unauthorized access attempts are logged and alerted upon, and access to this database is audited manually on a monthly basis.

I would select “Trust no one: validate (and sanitize if special circumstances apply) all data, even from your own database.” I firmly believe that if every application performed strict input validation, the internet would instantly be a much safer place.

I would remove HTTPS, because I know the business would put it back in. Browsers will stop users from visiting sites that do not have HTTPS on their sites, and from a business perspective that just will not fly. Thus, I would choose that one.

1. When an API sends data to another API
2. On a virtual machine that is powered off
3. When stored in a database
4. When sent from the server to the browser

All of them

We can either review each one of them manually or use a software composition analysis tool.

Using a secret store to hold your application's secrets is the best way to access and store your secrets safely (credentials, passwords, hashes, connection strings, etc.).

Credentials (username and password), connection strings, passwords, hashes.

1) People will try to log in as someone else by brute forcing credentials.

Likelihood: High

Risk: High

Mitigation to make the risk low: Block after 10 attempts.

2) Credential stuffing attacks (using stolen/breached credentials).

Likelihood: High

Risk: Critical

Mitigation: Enforce MFA for users, sign up for a service that will alert your company when your user's credentials on other sites have been breached so you can force reset, allow use of password managers and “copy and paste” on password fields, do not force password rotation or security questions.

3) Users attempting to create race conditions so they can “multiply” their money.

Likelihood: Low

Risk: Medium

Mitigation: Test thoroughly for race conditions and implement “locking” on bank balances while performing such transactions.

1) Car operating system crashes, causing the owner to be unable to use their car. Threat to availability.

Likelihood: Low

Potential Damage: Very angry users who need to go somewhere but cannot. This would cause harm to the company's reputation.

2) Car operating system contracts a virus or malware.

Likelihood: Low

Potential Damage: Very angry users who need to go somewhere but cannot. Could potentially attempt to ransom the control of the car to the user. This would cause harm to the company's reputation.

3) Car's GPS data and other data is stolen. Threat to confidentiality.

Likelihood: Low

Potential Damage: Harm to company's reputation, potential great harm to the user. If the owner of the car goes to secret military bases, or has a stalker, their whereabouts could be very sensitive information.

1) Authorization

2) Authentication

3) Access Control

4) Anti-CSRF token passing

5) Input validation functions

User Account:

1) To read your email

2) To access company files and log in to systems to use as an employee

Service Account:

1) To access the database from a web application

2) To access online storage from an API

1) Companies don't have the money to re-write everything into a brand-new language just because it will be better for security. Budgets exist for a reason.

2) Hiring Rust programmers may be more difficult than C/C++.

3) Not everyone has heard of Rust and its benefits.

4) “Because that's the way we've always done it.” Which is always the wrong answer, no matter the question.

I prefer .Net, because I had the most experience with it, it's well supported, there is tons of documentation available, and it's a very secure framework.

I would select .Net, because 1) I used to work at Microsoft and have first-hand knowledge of how seriously they take security, 2) because it is maintained by a company (rather than volunteers), there is more time and attention dedicated to it and it will never be “dropped” or left unmaintained, and 3) because it is proprietary, which means no one but a Microsoft employee could work on it, unlike open source frameworks. Each employee passes background checks and is given ethics and security training on a regular basis, ensuring the best possible outcome. People working on open source projects are rarely under such scrutiny before they are given access to the code.

That said, you can still use lots of open source.

An unprotected user session can be “hijacked,” meaning a malicious actor could take it over and use the system as though they are you. With that power they could empty your bank account, order ugly shoes that you don't approve of, or use your Twitter account to ask people to send you bitcoin (but the bitcoin wallet, of course, is theirs, not yours). The possibilities are endless.

They can send your money anywhere they want, including to a terrorist group in order to frame you for a crime. A creative malicious actor can do quite a bit of damage in a short amount of time, with your user session.

Authentication is a computer verifying you are the real you (and not someone else pretending to be you). Authorization is a computer deciding what you can and cannot do in its systems.

C-level executives will often argue that they “deserve” special systems and network access, but often there is no technical reason that they need them. As they are often the targets of spear-phishing campaigns, it is extremely important you apply least privilege to their access. That said, they have the power to fire you, so do the best you can to protect your organization, without getting fired. Explaining the risks to them will definitely help.

Network administrators need special privileges in order to perform their job duties. Ideally, they would log in to their email and use the internet with a regular set of credentials (no admin powers) and then use their account(s) with special powers separately. Either by logging in again or using the feature in Windows OS where you can right-click something and say “run as administrator.” They will need access to all network settings and systems, as a bare minimum.

Help Desk personnel need special privileges in order to perform their job duties. Ideally, they would log in to their email and use the internet with a regular (non-admin) set of credentials and then use their account(s) with special powers separately. Either by logging in again or using the features in Windows OS where you can right-click something and say “run as administrator.” They would need access to reset user passwords, access control, and quite a bit more in order to perform their job functions.

Dear Boss,

When we had an incident last month and you asked me to investigate, I could not. There were no logs to look at, and I was unable to explain how our data got onto the dark web; we only knew that it was there. I had received an alert from my application, saying something was wrong, but having no logs, I could not further our investigation. It was very frustrating to not be able to provide you an answer. I want to protect our organization the best I can, and to do that I need to know what happens during an incident, so I can prevent it from ever happening again. With this in mind, I ask you to help me find the budget so that we can turn on logging.

Thank you,

The AppSec Team

Dear Teammate,

I was reviewing your design document and noticed you are going to accept serialized objects from the public and this has me concerned, from a security perspective. Usually when we accept data or anything else from the public, we validate it, scan it, and treat it as though it's radioactive, until proven otherwise. If something is in a serialized state, that means we need to deserialize it in order to start that process. When we deserialize an object it could easily contain an attack within it, and we would have let them right into our network. Insecure deserialization is so scary it's on the OWASP Top Ten; it's very serious. Could we plan a meeting to find a less risky way to get you the data you need? I'm sure we can find a compromise that works for both of us.

Cheers,

The AppSec Team

No. It is a great awareness document, a place to start, and an excellent lesson to teach, but it is not a standard.

Cross-Site Scripting, Injection, and Logging. (There are more than three.)

No, it only applies to XML. That said, deserialization does apply to JSON, YAML, and even my beloved .Net.

Starbucks had a great race condition reported to their bug bounty. The security researcher (Egor Homakov) could get unlimited fancy coffee doing several transfers from one card to a second card, at almost the same time. The verification did not create a “lock” on the account balance, so when they all checked at the same time the money had not yet been removed from card #1, allowing many transfers to happen despite the balance on the first card being zero.

Alice is trying to buy a coffee on a mobile app, but part way through, her cellular signal dies. The steps are: she presses “buy,” it removes the money from her account, it sends the order to the local coffee shop, then it sends a confirmation to her. If she lost signal after it took her money, but before it sent the order, Alice has paid for a coffee but 1) doesn't get the coffee and 2) is unaware they took her money. She only knows that she did not get the coffee. Rolling everything back means the app can tell Alice to order again, and she will only be charged once.

User Acceptance Testing. Although this is a book about security, we cannot ignore the fact that the app has to work. Next up would be a security assessment or penetration test, but, ideally, we are able to perform all sorts of testing to ensure the app is in good shape.

Unit testing, because it's automated and made to run fast.

Penetration testing, because it must be thorough.

Injection, because it is the most dangerous. XSS, because it is the most pervasive.

Only you can answer this.

Only you can answer this.

No! SAST is very slow and produces many false positives. Instead choose one of the following: run SAST only on the brand new code or 2) run SAST outside the pipeline, analyze the results yourself, and then put the results into the bug tracker. Try putting secret scanning, SCA, or passive DAST scans into your pipeline instead.

If you do not check your code changes into version control, eventually someone else will check in their changes and push to prod and copy over your changes. All your hard work disappears in an instant. Talk about a bad day.

I believe that integration testing is equally important as testing the system itself. This is because if the systems don't work together, then it will appear to the end user as though it is broken. The end user doesn't usually care why they can't use a system, just that it's broken.

Your data is extremely valuable, so of course you need to protect it. Also, your app touches your database, and if your app is not secure your database could still defend itself.

You need to secure all of your tech, even if it is not public facing, due to insider threats, the possibility of someone getting into the network from the outside, or an insecure system reaching inside the network and contacting your system.

If you have less time, doing a security assessment makes sense. If the system is very delicate, a security assessment might make more sense. If you need to have full validation of your results, if you need to get management's attention, a penetration test is better.

When an incident happens and the application that was attacked is on the inventory page (in the configuration management DB), you have all the information possible to help you investigate in a timely manner.

If a call to an API has a <script> tag in it, you issue an alert because someone is attempting to inject code into your system.

Testing is the verification that your efforts to secure your application have been effective (or not). I do not feel it is the most important part to ensure you software is secure, but it does provide evidence that your efforts were effective. It also catches all the things you have missed.

Ensuring your code is secure is always #1. A WAF or RASP is an additional layer of defense.

If an application has had an SQL injection attack, we would need to developer to help us fix the bug, get access to the correct logs, and understand what happened.

DAST, because it's easy to use and finds low-hanging fruit. Specifically, I would choose OWASP Zap because it's free and a great tool.

I would give them this book! ;-D

SAST analyzes the code your team wrote for security issues. SCA looks only at the third-party components (the code you did not write).

SAST is a static analysis of your code, while DAST is dynamic analysis of your running application.

Only you can answer this.

It means that some of the responsibility in ensuring your cloud instance is yours, and some is your provider/vendor's. It's about who has to do what, so that nothing gets missed.

IaaS is a VM provided by a cloud provider that you need to patch and maintain. PaaS is a platform provided by a cloud provider that hosts your app, that you do not need to patch.

If you are using online storage, it is likely that it's always Available (CIA). But if it's online, there is more risk that if it's been misconfigured that it could be more easily found in order to be broken into.

You are risking external resources having access and/or control over your systems (the cloud provider employees).

A container is a virtualized, bare-minimum operating system for running one application. A virtual machine is a complete, virtualized operating system, to run one or more applications. A physical server is a machine that can hold one operating system, many operating systems (via virtualization), or many containers.

If there's a mechanical server failure you can deploy your server OS again in seconds! Also, you can use version control to do change management. There are many, many benefits; try to think of a few more yourself.

Releasing small changes often means you can fix a security bug very quickly. Win!

Only you can answer this.

Only you can answer this.

Only you can answer this.

1) Being so far behind in your version of a framework that you need to re-write your entire app in order to upgrade.

2) Having everything so far behind that it is near-impossible to release bug fixes.

3) Having 11 different versions of the same framework released in prod for your programming language, a zero day comes out, and you have no idea which one(s) are vulnerable.

Anything that might embarrass or harm you or your loved ones, get you fired, or can be used against you, should not be put on the internet. Data can be leaked or breached, mistakes can happen, and friends can prove untrustworthy. Also: the internet never forgets.

Adoption rates are low because it's extra work and people are lazy and because most people don't understand how much more it protects them and how much risk they are accepting when they put information online.

We could increase adoption of MFA by

1) Making it less complex to implement;

2) Making it mandatory at work;

3) Providing user training on its value and how to use it.

I use 1Password, but any password manager is better than none.

This is something you must answer for yourself. However, an example could be password rotation. It makes it very difficult for the average user to remember their passwords, so they often write them down or use a system of adding a number to the end, which makes the entire situation less-secure.

Rolling back a database or application, testing out your Business Continuity (BCP) or Disaster Recovery (DR) plans.