Q: If you use a cloud provider (GCP/AWS/Azure/etc)
A: I don't use a cloud provider
Q: Describe how credentials are provisioned, managed, and stored.
A: Credentials to what exactly? Since I don't use a cloud provider all the data including credentials are safe and secure on the server hosting everything.
Q: If an attacker gained access to an individual developer’s cloud credentials
A: The only developer is me. Anything besides what I trigger myself I would notice immediately as out of the ordinary.
Q: What actions could that attacker perform?
A: Not much. Externally facing applications are containerized and have access only to the level of access to data that they should. They would not gain any control of the system
Q: How would you detect and respond to the breach?
A: I'd notice activity in the logs which are monitored for unusual activity. I also check them manually myself besides the automatic monitoring rules.
Q: If you don’t use a cloud provider: why not?
A: They are overpriced and I don't trust them.
Q: Describe how staff authenticate to company services (e.g. servers, email, SaaS products), particularly highlighting your use of password managers, 2FA, and SSO.
A: Passwords? What b.s. is that. Certs all the way.
Q: What development practices do you use to protect against the OWASP Top 10?
1. Injection. A: Only parameterized queries are used. Non-issue.
2. Broken auth. A: Only use reliable session/auth stuffs and/or look carefully at the details of how it works. Don't use crap.
3. Sensitive data exposure. A: APIs only expose the data needed and all access is logged and monitored.
4. XML External Entities. A: I don't use crappy XML parsers with such vulns.
5. Broken access control. A: All applications I run were written by myself and access levels only have access to just the needed data. That access level flows to all places data is accessed. Nothing is given access without an associated current valid session and auth level.
6. Security misconfiguration. A: System is hardened. Containers are used. Everything is kept up to date to the bleeding edge at all times. No legacy crap is used.
7. XSS. A: All access is in house. No external entities are loaded period. I trust no one. All entered data is carefully output in a way to prevent user entered data from having influence on code. Eg: No user data is trusted and everything is validated as being, essentially, plaintext.
8. Insecure deserialization: A: No outside entities are deserialized since I don't accept any. Anything that could have been altered by a user, the parsers are all secure state machines which cannot possibly have any influence on the system.
9. Using Components with Known Vulnerabilities. A: I trust nothing, including libraries. I review the code of many many many things. Obviously cannot review everything but I at least choose libraries that are kept up to data and regularly worked on / used by others. I am sure there are 0days present that aren't public yet, but even if they were taken advantage of they wouldn't get access to much.
10. Insufficient Logging & Monitoring. A: All access and operations that affect data are logged. Read access is also logged and monitored to some extent.
Describe the steps a developer or operations person takes to push new code to production.
Have you had any security breaches in the last two years?
If yes: please explain the breach, and provide copies of any postmortem/root cause analysis/after-action reports.
Q: Describe how credentials are provisioned, managed, and stored. A: Credentials to what exactly? Since I don't use a cloud provider all the data including credentials are safe and secure on the server hosting everything.
Q: If an attacker gained access to an individual developer’s cloud credentials A: The only developer is me. Anything besides what I trigger myself I would notice immediately as out of the ordinary.
Q: What actions could that attacker perform? A: Not much. Externally facing applications are containerized and have access only to the level of access to data that they should. They would not gain any control of the system
Q: How would you detect and respond to the breach? A: I'd notice activity in the logs which are monitored for unusual activity. I also check them manually myself besides the automatic monitoring rules.
Q: If you don’t use a cloud provider: why not? A: They are overpriced and I don't trust them.
Q: Describe how staff authenticate to company services (e.g. servers, email, SaaS products), particularly highlighting your use of password managers, 2FA, and SSO. A: Passwords? What b.s. is that. Certs all the way.
Q: What development practices do you use to protect against the OWASP Top 10?
1. Injection. A: Only parameterized queries are used. Non-issue.
2. Broken auth. A: Only use reliable session/auth stuffs and/or look carefully at the details of how it works. Don't use crap.
3. Sensitive data exposure. A: APIs only expose the data needed and all access is logged and monitored.
4. XML External Entities. A: I don't use crappy XML parsers with such vulns.
5. Broken access control. A: All applications I run were written by myself and access levels only have access to just the needed data. That access level flows to all places data is accessed. Nothing is given access without an associated current valid session and auth level.
6. Security misconfiguration. A: System is hardened. Containers are used. Everything is kept up to date to the bleeding edge at all times. No legacy crap is used.
7. XSS. A: All access is in house. No external entities are loaded period. I trust no one. All entered data is carefully output in a way to prevent user entered data from having influence on code. Eg: No user data is trusted and everything is validated as being, essentially, plaintext.
8. Insecure deserialization: A: No outside entities are deserialized since I don't accept any. Anything that could have been altered by a user, the parsers are all secure state machines which cannot possibly have any influence on the system.
9. Using Components with Known Vulnerabilities. A: I trust nothing, including libraries. I review the code of many many many things. Obviously cannot review everything but I at least choose libraries that are kept up to data and regularly worked on / used by others. I am sure there are 0days present that aren't public yet, but even if they were taken advantage of they wouldn't get access to much.
10. Insufficient Logging & Monitoring. A: All access and operations that affect data are logged. Read access is also logged and monitored to some extent. Describe the steps a developer or operations person takes to push new code to production. Have you had any security breaches in the last two years? If yes: please explain the breach, and provide copies of any postmortem/root cause analysis/after-action reports.