try! Swift: security workshop quiz
Hello, thank you for your interest in "Security data management for app devs" workshop at try! Swift world.
During workshop we will discuss "tough" security-related things that developers should keep in mind, like data privacy regulations, risks models and risk vectors, appsec guidelines and cheatsheets.
You will benefit from this workshop better if you already have basic understanding of mobile app security. This quiz has 10 questions to find your interests and white spots.
If you get less that 80% scores in the quiz, this workshop might be too complicated for you. Don’t worry, you can still attend, but don’t be hard on yourself and give yourself more time to read materials after workshop
- Anastasiia aka @vixentael with 🧡
1. What is sensitive data that we need protect in the app:
PII, names, emails
user passwords and encryption keys
logs, keys, API tokens
location, passport photo
all of the above
depends on the threat model and business risks
2. OWASP MASVS –
software assurance maturity model
checklist to find bugs and vulnerabilities, standard that aims to make security measurable
part of development process to build new features
3. OWASP SSDLC — a process that means
we should run pentests once in 3 months
secure software development lifecycle, we should take care about security while building every feature of our app
we should write tests
we should attend security awareness trainings
4. "Secure by default" means
software I create is always secure
I can configure security functions in software after installation
I create software that enables security functions by default (like uses HTTPS with TLS v1.2+ by default)
5. When building new feature I think about security...
when gathering requirements, I care to have security requirements into feature description / acceptance criteria
when implementing the feature, only if I know that security could be a concern here
when feature is ready, then I test it for security (logs, accesses, non-auth API)
when feature is deployed, then someone tests it for security
all of the above
6. Security risk can be calculated as "risk = impact X probability / cost" which means
security risks make sense for large enterprise apps with millions of users
why bother calculating risks if we can use mobile security guidelines
every app feature implies some security risk, bigger risk means we should spend more time on security to decrease the risk
every app feature implies some security risk, but risks are complicated to calculate, so security should be applied evenly on every feature
7. "Security control" is best described as
code or module or org process that prevents security risks
authorization, authentication, access control
firewall that watches all connections
KeyChain and SecureEnclave
8. It's safe to store sensitive data in iOS app
in Keychain with biometric protection
in UserDefaults but encrypted
do not store at all
depends on app risks and threats model
9. Select cryptographic libraries
10. From security stand point it makes sense to log...
access to sensitive data (access, decryption, failed attempts to access)
exceptions and errors
attempts to use invalid tokens
actions from suspicious users
Thank you! Put your contacts / twitter if you want
Page 1 of 1
Never submit passwords through Google Forms.
This content is neither created nor endorsed by Google.
Terms of Service