Security Engineering at Google: My Interview Study Notes
I am a security engineer at Google and these are the notes from when I was studying for the interviews. This is my first job in security and a lot of people have asked me how I studied. My notes consist mostly of a list of terms and technologies to learn, plus little tidbits that helped me remember certain details. At the end are interview tips I made for myself and that I find myself saying to others looking to interview.
If you are less confident at coding: Spend more time writing small scrips and studying features of your preferred language. Coding is essential (even if you don't like it or you don't use it much in your current role). I have a section on coding in this list.
If you are less confident at security topics: I recommend doing a lot of reading and whenever you come across a term you are unfamiliar with or couldn't easily explain, then add it to the list.
- Web application
- Infrastructure (Prod / Cloud) Virtualisation
- OS implementation and systems
- Cryptography, authentication, identity
- Malware & Reversing
- Incident Management
- Coding & algorithms
- Security themed coding challenges
- Learning tips
- Interviewing tips
- Application; layer 7 (and basically layers 5 & 6) (includes API, HTTP, etc).
- Transport; layer 4 (TCP/UDP).
- Network; layer 3 (Routing).
- Datalink; layer 2 (Error checking and frame synchronisation).
- Physical; layer 1 (bits over fibre).
- Rules to prevent incoming and outgoing connections.
- Useful to understand IPv4 vs IPv6.
- Requests to DNS are usually UDP, unless the server gives a redirect notice asking for a TCP connection. Look up in cache happens first. DNS exfiltration. Using raw IP addresses means no DNS logs, but there are HTTP logs. DNS sinkholes.
- In a reverse DNS lookup, PTR might contain- 126.96.36.199.in-addr.arpa, which will map to 188.8.131.52. DNS lookups start at the end of the string and work backwards, which is why the IP address is backwards in PTR.
- Sending data as subdomains.
- Doesn’t show up in http logs.
- Start of Authority (SOA).
- IP addresses (A and AAAA).
- SMTP mail exchangers (MX).
- Name servers (NS).
- Pointers for reverse DNS lookups (PTR).
- Domain name aliases (CNAME).
- Pair MAC address with IP Address for IP connections.
- UDP (67, 68)
- Dynamic address allocation (allocated by router).
- timeshare, statistical share, just useful to know it exists.
- Usually uses UDP, but might also use ICMP Echo Request or TCP SYN. TTL, or hop-limit.
- Initial hop-limit is 128 for windows and 64 for *nix. Destination returns ICMP Echo Reply.
- Network scanning tool.
- Understand PKI (public key infrastructure in relation to this).
- Hide traffic from ISP but expose traffic to VPN provider.
- Traffic is obvious on a network.
- How do organised crime investigators find people on tor networks.
- Why 7 proxies won’t help you.
- Border Gateway Protocol.
- Holds the internet together.
Network traffic tools
- Burp suite
- (80, 443)
- Super important to learn this, includes learning about handshakes, encryption, signing, certificate authorities, trust systems.
- Web traffic, chat, voip, traceroute.
- TCP will throttle back if packets are lost but UDP doesn't.
- Streaming can slow network TCP connections sharing the same network.
- Ping and traceroute.
- SMTP (25, 587, 465)
- IMAP (143, 993)
- POP3 (110, 995)
- Handshake uses asymmetric encryption to exchange symmetric key.
- (23, 992)
- Allows remote communication with hosts.
- Who is 0.0.0.0? Tell 0.0.0.1.
- Linking IP address to MAC, Looks at cache first.
- (67, 68) (546, 547)
- Dynamic (leases IP address, not persistent).
- Automatic (leases IP address and remembers MAC and IP pairing in a table).
- Manual (static IP set by administrator).
- Understand use by hackers (botnets).
- (21, 22)
- Predefined set of tasks that remote clients can execute.
- Used inside orgs.
- 0 - 1023- reserved for common services - sudo required.
- 1024 - 49151- registered ports used for IANA-registered services.
- 49152 - 65535- dynamic ports that can be used for anything.
- | Verb | Path | HTTP version |
- Accept-encoding(compression type)
- Connection- close or keep-alive
- Return address
- Expected Size?
HTTP Response Header
- HTTP version
- Code- 200 OK, 403 forbidden, 404 not found, 500 server, 503 server unavailable, 301 Redirect notice
- Type of data in response
- Type of encoding
- Source port
- Destination port
Broadcast domains and collision domains.
CAM table overflow
Same origin policy
- Only accept requests from the same origin domain.
- Cross-Origin Resource Sharing. Can specify allowed origins in HTTP headers. Sends a preflight request with options set asking if the server approves, and if the server approves, then the actual request is sent (eg. should client send auth cookies).
- Policies, eg what websites use HTTPS.
- Can verify certificates against public logs
HTTP Public Key Pinning
- Deprecated by Google Chrome
- Cross-Site Request Forgery.
- Reflected XSS.
- Persistent XSS.
- DOM based /client-side XSS.
<img scr=””>will often load content from other websites, making a cross-origin HTTP request.
- (Wo)man in the browser (flash / java applets) (malware).
- Validation / sanitisation of webforms.
- Form data.
- Visible from URL.
- Find directories on the server you’re not meant to be able to see.
- There are tools that do this.
- Think about what information they return.
- And what can be sent.
- Get info about Chrome extensions.
- Is this a legitimate browser? Or a botnet?
Browser extension take-overs
- Miners, cred stealers, adware.
Local file inclusion
Remote file inclusion (not as common these days)
- Server Side Request Forgery.
Web vuln scanners
Infrastructure (Prod / Cloud) Virtualisation
- Escaping and privilege escalation techniques
- Site isolation
- Network connections from VMs / containers
- Side-channel attacks
- Trusting the host but not the network.
OS implementation and systems
Privilege escalation techniques, and prevention
Directory traversal (prevention)
Remote Code Execution / getting shells
- Some messaging apps use sqlite for storing messages.
- Useful for digital forensics, especially on phones.
- Windows registry and group policy.
- Windows SMB.
- Samba (with SMB).
- Buffer Overflows.
- Kernel, userspace, permissions.
- MAC vs DAC.
- /tmp - code can be saved here and executed.
- LDAP - Lightweight Directory Browsing Protocol. Lets users have one password for many services. This is similar to Active Directory in windows.
- Gotofail error (SSL).
- Research Mac vulnerabilities.
Data Execution Prevention
Address space layout randomisation
- To make it harder for buffer overruns to execute privileged instructions at known addresses in memory.
Principle of least privilege
- Eg running Internet Explorer with the Administrator SID disabled in the process token. Reduces the ability of buffer overrun exploits to run as elevated user.
- Requiring kernel mode code to be digitally signed.
Compiler security features
- Use of compilers that trap buffer overruns.
- Of software and/or firmware components.
Mandatory Access Controls
- Operating systems with Mandatory Access Controls - eg. SELinux.
"Insecure by exception"
- When to allow people to do certain things for their job, and how to improve everything else. Don't try to "fix" security, just improve it by 99%.
Do not blame the user
- Security is about protecting people, we should build technology that people can trust, not constantly blame users.
Cryptography, authentication, identity
Encryption vs Encoding vs Hashing vs Obfuscation vs Signing
- Be able to explain the differences between these things.
Encryption standards + implementations
- RSA (asymmetrical).
- AES (symmetrical).
- ECC (namely ed25519) (asymmetric).
- Chacha/Salsa (symmetric).
Asymmetric vs symmetric
- Asymmetric is slow, but good for establishing a trusted connection.
- Symmetric has a shared key and is faster. Protocols often use asymmetric to transfer symmetric key.
- Perfect forward secrecy - eg Signal uses this.
Cyphers - Block vs stream
Trusted Platform Module
- Trusted storage for certs and auth data locally on device/host.
- MD5, Sha-1), BLAKE.
- Used for identifiers, very useful for fingerprinting malware samples.
- PRNG (pseudo random number generators).
- Entropy buffer draining.
- Methods of filling entropy buffer.
- What info do certs contain, how are they signed?
- Look at DigiNotar.
- Bearer tokens, this can be stolen and used, just like cookies.
- Client side.
- Server side.
- Can't rotate unlike passwords.
- Rotating passwords (and why this is bad).
- Different password lockers.
U2F / FIDO
- Eg. Yubikeys.
- Helps prevent successful phishing of credentials.
Compare and contrast multi-factor auth methods
Malware & Reversing
- Morris worm.
- Zeus malware.
- Various methods of getting remote code execution.
- Process hollowing.
- Multi-vector and polymorphic attacks.
- RAT (remote access trojan) features.
- Obfuscation of code, unique strings (you can use for identifying code).
- IdaPro, Ghidra.
Static / dynamic analysis
- Describe the differences.
- Virus total.
- Hybrid Analysis.
Three ways to attack - Social, Physical, Network
- Ask the person for access, phishing.
- Cognitive biases - look at how these are exploited.
- Spear phishing.
- Water holing.
- Baiting (dropping CDs or USB drivers and hoping people use them).
- Get hard drive access, will it be encrypted?
- Boot from linux.
- Brute force password.
- Frequency jamming (bluetooth/wifi).
- Covert listening devices.
- Hidden cameras.
- Disk encryption.
- Trusted Platform Module.
- Spying via unintentional radio or electrical signals, sounds, and vibrations (TEMPEST - NSA).
- Find CVEs for any services running.
- Interception attacks.
- Getting unsecured info over the network.
- Remote code execution and privilege.
- Bind shell (opens port and waits for attacker).
- Reverse shell (connects to port on attackers C2 server).
- Email spoofing.
- IP address spoofing.
- MAC spoofing.
- Biometric spoofing.
- ARP spoofing.
- Shodan - Google but for devices/servers connected to the internet.
- Google the version number of anything to look for exploits.
- Hak5 tools.
Look at mitre attack matrix
- Intrusion Detection System (signature based (eg. snort) or behaviour based).
- System Information and Event Management.
- Indicator of compromise (often shared amongst orgs/groups).
Things that create signals
- Honeypots, snort.
Things that triage signals
- SIEM, eg splunk.
Things that will alert a human
- Automatic triage of collated logs, machine learning.
- Notifications and analyst fatigue.
- Systems that make it easy to decide if alert is actual hacks or not.
- Host-based signatures
- Eg changes to the registry, files created or modified.
- Strings in found in malware samples appearing in binaries installed on hosts (/Antivirus).
- Network signatures
- Eg checking DNS records for attempts to contact C2 (command and control) servers.
- Host-based signatures
Anomaly / Behaviour based detection
- IDS learns model of “normal” behaviour, then can detect things that deviate too far from normal - eg unusual urls being accessed, user specific- login times / usual work hours, normal files accessed.
- Can also look for things that a hacker might specifically do (eg, HISTFILE commands, accessing /proc).
- If someone is inside the network- If action could be suspicious, increase log verbosity for that user.
- Brute force (trying to log in with a lot of failures).
- Detecting port scanning (could look for TCP SYN packets with no following SYN ACK/ half connections).
- Antivirus software notifications.
- Large amounts of upload traffic.
- Canary tokens.
- Dummy internal service / web server, can check traffic, see what attacker tries.
Things to know about attackers
- Slow attacks are harder to detect.
- Attacker can spoof packets that look like other types of attacks, deliberately create a lot of noise.
- Attacker can spoof IP address sending packets, but can check TTL of packets and TTL of reverse lookup to find spoofed addresses.
- Correlating IPs with physical location (is difficult and inaccurate often).
Logs to look at
- DNS queries to suspicious domains.
- HTTP headers could contain wonky information.
- Metadata of files (eg. author of file) (more forensics?).
- Traffic volume.
- Traffic patterns.
- Execution logs.
Detection related tools
Privacy incidents vs information security incidents
Know when to talk to legal, users, managers, directors.
Run a scenario from A to Z, how would you ...
Good practices for running incidents
- How to delegate.
- Who does what role.
- How is communication managed + methods of communication.
- When to stop an attack.
- Understand risk of alerting attacker.
- Ways an attacker may clean up / hide their attack.
- When / how to inform upper management (manage expectations).
- Metrics to assign Priorities (e.g. what needs to happen until you increase the prio for a case)
- Use playbooks if available
Important things to know and understand
- Type of alerts, how these are triggered.
- Finding the root cause.
- Symptom vs Cause.
- First principles vs in depth systems knowledge (why both are good).
- Building timeline of events.
- Understand why you should assume good intent, and how to work with people rather than against them.
- Prevent future incidents with the same root cause
Coding & algorithms
- Quicksort, merge sort.
- Binary vs linear.
- For space and time.
- O(n), but O(n!) when matching.
- It's useful to be familiar with basic regex syntax, too.
- And why it is rarely used.
- List comprehensions and generators [ x for x in range() ].
- Iterators and generators.
- Slicing [start:stop:step].
- Regular expressions.
- Types (dynamic types), data structures.
- Pros and cons of Python vs C, Java, etc.
- Understand common functions very well, be comfortable in the language.
- Dictionaries / hash tables (array of linked lists, or sometimes a BST).
Security themed coding challenges
Cyphers / encryption algorithms
- Be able to implement basic cyphers.
Parse arbitrary logs
- Practice text parsing.
- Another way to practice text parsing.
- Practice parsing network information.
- How would you build ssh botnet.
Scrape meta data from PDFs
Script to recover deleted items
A program that looks for malware signatures in binaries / code samples
Track concepts - "To learn", "Revising", "Done"
- Any terms I couldn't easily explain went on to post-its.
- One term per post-it.
- "To learn", "Revising", "Done" was written on my whiteboard and I moved my post-its between these categories, I attended to this every few days.
- I looked up terms everyday, and I practiced recalling terms and explaining them to myself every time I remembered I had these interviews coming up (frequently).
- I carried around a notebook and wrote down terms and explanations.
Target your learning
- Think hard about what specific team you are going for, what skills do they want? If you aren't sure, then ask someone who will definitely know.
Identify your weaknesses.
- If you're weak on coding and you find yourself avoiding it, then spend most of your study time doing that.
- Read relevant books (you don't have to read back to back).
- When looking up things online, avoid going more than two referral links deep - this will save you from browser tab hell.
- Take care of your basic needs first - sleep, eat well, drink water, gentle exercise. You know yourself, so do what's best for you.
- You are more than your economic output, remember to separate your self worth from your paycheque.
- See interviews for what they are - they are not a measure of you being "good enough".
- Questions create thirst for answers.
- Ask questions to yourself when you’re studying, to the people you are studying with.
- Questions reveal how you approach problems.
- Ask your interviewer lots of questions. They often intentionally ask questions with few details.
Say what you are thinking
- The interviewer can only make an evaluation on your suitability for the job based on the things you say.
- If you don't say your thought process aloud, then the interviewer doesn't know what you know.
- Practice saying everything you know about a topic, even details you think might be irrelevant.
Reduce cognitive load
- If the infrastructure is complicated, draw up what you think it looks like.
- Write tests and expected output for code you write, test your code against it.
- Take notes about the questions so you don't forget important details.
- Prepare questions that you want to ask your interviewers so you don't need to think of them on the spot on the day. Since an interview is also for you to know more about the workplace, I asked questions about the worst part of the job.
- Bring some small snacks in a box or container that isn't noisy and distracting. A little bit of sugar throughout the day can help your problem solving abilities.
- Stay hydrated - and take a toilet break between every interview if you need to.
Do practice interviews
- Do them until it's comfortable and you can easily talk through problems
- Ask them to give you really hard questions that you definitely don't know how to answer
- Practice being in the uncomfortable position where you have no idea about the topic you've been asked. Work through it from first principles.
- Doooo theeeeemmm yes they can be annoying to organise but it is worth it.