Winter opportunity: Security Research and Response Group / RIM

Hey, Everybody!

I'm currently working at the Security Research and Response Group (SRRG) here at Research In Motion (RIM). SRRG is RIM's internal hacking squad, responsible for security testing products before they ship, and responding to any security problems that come up for products already in the wild.

SRRG is looking for the right people to join our team as Security Research Analysts. It's a great opportunity to dig into network security, either through finding vulnerabilities or developing security research tools (or a little of each). Lots more details on the position below.

This is the job I'm doing right now, and I'm loving it. RIM is really a great company to work for, and the group is a lot of fun.

I know the requirements sound a little daunting, but don't be afraid to toss your hat into the ring. They're certainly not going to turn away the right people because you don't happen to match a checklist.

If you're interested, browse to http://www.rim.com/careers, click "Students", and apply for position J0707-1073.

One more thing: If you have any questions about this position, don't hesitate to ask! You can reach me by e-mail: dsuffling [@] rim [.] com.

==================================================================

Hello from the Security Research and Response Group (SRRG) at Research In Motion in Waterloo.

This is a bit more specific description of what we do than was included in the job posting to which you applied. Hopefully by giving you some information prior to an interview, we can save some time and get right to the good stuff in person, namely determining why you're a good candidate for our team.

What We Do
===========
Research
--------
The SRRG is responsible for theorizing, studying and demonstrating attacks on BlackBerry technology. This is the "Research" component of our work, which covers:
1. BlackBerry Handheld Operating Environment - BlackBerry proprietary JVM, OS and ARM10 architecture
2. BlackBerry Handheld Applications - APIs, core applications (email, browser, etc) and malicious code
3. Wireless/Cellular transport - GSM, GPRS, EDGE, UMTS, CDMA, 802.xx etc.
4. Network Protocols - IP, UDP, TCP, and a number of RIM-proprietary protocols
5. BlackBerry Service Infrastructure - RIM's service infrastructure including device provisioning, registration, and device/server data flow
6. BlackBerry Enterprise Server (BES) - server software and associated databases

Our research efforts also involve providing timely intelligence, analysis and commentary to a variety of internal clients. This includes;
- design review consulting with Engineering. (E.g. "If I implement my parser this way, what are the potential security holes?")
- evaluation of technology under consideration for integration with BlackBerry (E.g. "Is this 3rd-party library secure?")
- answering security-related questions from customer-facing RIM staff like account managers, sales, and support groups. (E.g. "Customer X wants to know if their Bluetooth headset-to-BlackBerry voice channel is secure. Is it?")

Internal education is an important component of our work with the goal being to raise awareness of security issues in engineering and to head off vulnerabilities before they make it into the product. We also convey trends in attack methodology so that development can be mindful of them when designing and implementing the next generation of BlackBerry. Education is handled in a number of ways including informal meetings, lunch-and-learn sessions and the occasional show-and-tell in which we show off some of the cooler things we've been working on.

Response
--------
The second 'R' in SRRG stands for Response. We investigate vulnerabilities that come to our attention from both inside and outside of RIM. This is time-critical work, so we drop what we're doing and go deep on reported problems to assess their validity, impact, and potential fixes.

What We Don't Do
================
* IT Security: We don't secure RIM's corporate networks, tweak firewall settings, etc.
* Facilities Security: We don't look at the physical security of RIM assets, lock the dumpsters, etc.
* Bug Fixing: We don't fix issues - we just find them, though we do often suggest and verify fixes.

It is a common misconception to equate our work with Quality Assurance (QA) in its usual sense. In the strictest sense, we are working to improve the quality of BlackBerry, but we do not engage the traditional QA activity of functional verification. This is handled by another team at RIM (SV&V).

What to Expect
==============
We're a small group and consequently serve as more of a security "spotlight" than an exhaustive validation mechanism. "Great," you say, "but what does all this mean for me on my work term?" Well, it means:

1. You'll be paired with a full-timer who can guide you on your research as well as help you navigate the administrivia of RIM.

2. Your first few days will include some background reading that goes deeper on the technology than what you might see in the general RIM orientation. During this time we'll also sort out the various accounts you need, take you out for lunch, show you where the pop machine is, etc.

3. Once you're settled, we'll talk about potential research projects for the term. We do our best to scope projects to fit the 15 usable weeks you're with us. We also consider your level of expertise in various technologies that we investigate. Before you arrive we try to come up with a list of candidate projects so you have some choice. If you have a burning passion for exploring a certain domain of vulnerability, please let us know and we'll do our best to match up your interest with the group's hot topics.

Your research project may break new ground for us, or it may involve picking up where a previous student left off. You will *definitely* be writing code (Java/C/ASM on device, C/C++/Python on Windows/Linux). The work often looks like this:
(a) research a piece of technology (scour for docs, talk to RIM subject-matter experts, find related externally-built tools)
(b) analyze for vulnerabilities (this often includes writing your own tools, and talking to subject-area developers)
(c) code exploits to illustrate vulnerabilities found (an exploit is worth a thousand words)
(d) report on vulnerabilities to us and development (point form is ok), classify the vuln by severity (we'll teach you how) and recommend potential fixes
(e) vulnerabilities get fixed by development

4. You leave with us artifacts of lasting value. Documents, diagrams, code, memorable presentations, good jokes. Your immediate value will hopefully be obvious and outstanding, but "lasting value" means we still refer to your docs or use the tools you wrote long after you've returned to school.

Examples of past co-op projects? It's a bit tricky to talk about this work since you're not yet under a non-disclosure agreement with RIM and much of the work we do is confidential, but in broad strokes, past SRRG coops have produced protocol analysers, fuzzers and other tailor made security tools.

Other Duties
============
1. Build/Research environments - being a small team with fairly specialized requirements, we often build out our own boxes with Linux, Win 2K3, VMWare, applications, tools, build setups for RIM software, etc. Basically whatever it takes to get the job done. We all do it.

2. SRRG Wiki Updates - we maintain our own wiki to save our future-selves the pain of forgetting stuff we've already learned. It also provides better continuity between co-op terms and flattens the learning curve for new researchers.

3. Work term report - we'll work with you to figure out a good topic. The rest is up to you.

Get Ready to Interview
======================
1. Tell us *why* you want *this* job. We all have our reasons for choosing this work. What are yours?

2. Be prepared to substantiate the content of your resume. If you claim to know about SQL injection, we're going to have you show us a SQL injection attack on the whiteboard. If you've claimed to be an expert in C++, get ready for some hard questions.

3. Be prepared for a technical interview. We need to assess your coding skills so you will stand up at the whiteboard and write code for us. We know it's slightly nerve-racking, but we've all done it. Just talk out loud so we can hear how you think.

4. Be honest about your skill levels. Please.

5. Tell us what you're really good at. Despite the vast list of skills we all list on our resumes, it is usually the case that individuals are really good at about two things. What are your two super-powers?

6. Extra-curricular tech stuff counts. Tell us if you've contributed to an open-source project. Tell us if you wrote a Tetris game in high school. Tell us if you built your own MP3 player for your car. Tell us if you wrote your own shell code to see how shell code works. Tell us if you published a paper on stealth aircraft detection via Doppler shift signatures.

7. Code samples. If you have a piece of code that *you* wrote that you're particularly proud of, please send it to us. Alternatively, if you can't think of any suitable code of your own, bring in someone else’s, but be prepared to explain where you got it and why you think it's clever.

8. If your interview is being conducted over the telephone, please try to be near a computer that can receive email. This is so that we can send code samples back and forth.

9. Your Google footprint. This goes back to point #2. If we can find you in Google it helps establish your technical credibility. Send us links. If you've used a nick/handle feel free to pass that on too.

10. Now relax.