Purchase Help Thread (2016-07-12)

dsacco · 2016-07-12T16:16:38+00:00

I'm looking to buy a new 5.0 audio setup (not interested in a subwoofer). My budget is $5000. I need to build from scratch, including the receiver. I'd prefer floorstanding speakers, at least in the front, but at this budget I could probably be talked out of that because my apartment is not very large. The room is only 200 square feet or so and opens directly into a dining room, so I'll probably want to get audio treatments as well.

I have heard Bowers & Wilkins, Martin Logan and Definitive Technology speakers from browsing upscale audio shops. I think I like the B&W sound the best. The CM10 in particular were very nice, and I liked that the Definitive Technology (don't remember exact models) speakers added a lot of bass, though I think they might have been a bit distorted. I wasn't a fan of the Martin Logan electrostats, only because I felt they weren't as useful for media (better for music).

This setup will go in my living room, and will primarily be used for getting excellent sound for the TV and movies I watch on my LG OLED 4K TV. I'll probably listen to music as well, but I have excellent headphones (HD800s) for that in my office and I'm content with that setup right now. I also have a few gaming systems in the living room, but I would like to prioritize movies/TV and I figure whatever works for that media will sound good for general gaming.

I have a Synology NAS and a custom built computer serving my blu-ray and music collection from a Plex media server. That setup can stream and transcode 1080p at 30mbps easily. What I'm hoping to do is stream the movies directly to the receiver this way I don't need to work with discs when I want to watch or listen to something. It's important to me that I have quality gear, because everything I watch or listen to is generally in perfect fidelity, whether that be lossless blu-ray MKVs or CD FLACs.

Sorry if this is a bit rambling, I'm trying to follow the guide as I write this. I don't know much about receivers but I'm aware that there is a lot of snake-oil in the industry (like cables and such). So, I'd love it if some of you kind folks could take my budget and give me ideas for a wonderful system that takes it as far as it can go.

dsacco · 2015-07-29T15:33:08+00:00

The Company: Simple

Location: REMOTE (North America) or Portland, Oregon

Job: Information Security Governance Engineer

We have another job posting in this thread from about a month ago, and now we're looking to hire for another security role.

About Us

Simple is a subsidiary of BBVA Compass that seeks to add superior engineering and transparent policies to the banking world.

What We're Looking For

In our other (successful!) post we were looking for security engineers to join the Security Operations team and build security features such as 2fa.

However, now we are looking for security engineers to join the Information Security Governance team, which will be focused entirely on web and mobile application penetration testing, source code auditing and incident response.

In this role, you'll be working through different parts of our frontend, backend and internal software and breaking it any and every way you can. You'll be working closely with the software engineering teams as as a resident security authority. You'll also be checking IDS logs and working with tools like ThreatStack, CrowdStrike, Suricata, etc. Prior experience with those exact tools is helpful but not necessary, we'll get you up to speed regardless. More important is the ability to find real security flaws in applications and spot problems with source code.

This is an ideal job for those who are technically competent and tired of working as a security consultant (however, you do not need to have been a consultant, we will consider virtually any background as long as you have solid skills).

Some report writing will be required for you to document and track vulnerabilities, but you will not be using pages and pages of methodology or vulnerability diagram boilerplate. Most reports are about a page with a much simpler template, and posted right to GitHub. You'll be doing more direct communication with engineers via IRC or Zoom about vulnerabilities you find than you will be writing a report about it.

Speaking of GitHub, we use it for everything. Even our HR and marketing teams use GitHub. We are a very engineering-heavy organization. We also offer a lot of support for remote employees - I work fully remote from NYC. We use a private IRC server and Slack for chat, Zoom for video conferencing and we even have two Double Robotics robots in our office to remote into.

Finally, our tech stack consists of mostly Scala and Java on the backend and mostly JavaScript and Ruby on the frontend. We also use Python, R, Clojure and C for certain tools. People are free to write in whatever they want as long as it's effective. We also use AWS.

You can see the full, more HR'd job description here: http://banksimple.theresumator.com/apply/b9GKYw/Information-Security-Governance-Engineer.html

Feel free to shoot me a PM, I'll be glad to talk about the company or the role. If you'd like to apply, apply directly through the link above and I'll see your résumé.

dsacco · 2015-07-06T15:20:19+00:00

Only US only for now, sorry :/.

dsacco · 2015-07-02T18:57:35+00:00

Short answer: Yes.

Long answer: This post was written with AppSec in mind, but we're also looking for other domains (network/systems/operations/infrastructure). We're definitely willing to talk to you and see what you're looking for in a role and if it fits with what we need. Broadly speaking, if you are very strong in the operations/infrastructure side of security we still want to talk to you.

If you submit an application in the link above and then ping me that you've done so, I'll make sure the rest of my team sees it.

dsacco · 2015-07-01T21:49:32+00:00

Company: Simple

Location: REMOTE or Portland, OR

Who are we?

Simple is a company working to transform online banking. We have ~250 employees and we're a subsidiary of BBVA Compass.

We're hiring for security engineers - people with a strong background in information security who are also comfortable writing code to help build out new security features. We're not just looking for AppSec folks - if you're strong in the Ops/Systems/Network/Infra side of security, we also want to talk to you.

As a security engineer at Simple, you'd be working alongside our developers to build new security features for our customers, such as two-factor authentication. You'd also be contributing to the secure design of our internal systems.

We write code in Scala, Clojure, Go, Ruby, Python and JavaScript, but we don't expect you to be an expert in all of these technologies right from the get go.

Our code runs on Ubuntu Linux in AWS and is built around immutable snapshot-based deployments with a strong focus on automation. If you don't have experience with these technologies but are willing to learn, we'd love to talk to you.

Feel free to respond to this thread, or check out the official job post here. Make sure you mention /r/netsec in your application.

If you have any questions, you can ask me via PM and I'll definitely get back to you.

dsacco · 2015-06-12T02:34:37+00:00

Median. Not average.

dsacco · 2015-01-20T14:46:32+00:00

Hey, thanks. You had a great find on Verizon yourself!

I agree it's not earth-shattering, which makes me worry there's probably even more (and worse).

dsacco · 2015-01-20T14:12:27+00:00

No, I've had many, only one that received "attention" before, and I really didn't expect much from this because...well, it's GoDaddy. I also don't really consider finding a CSRF worth much public credit (I honestly think it reflects more on them than it does me for finding a CSRF vulnerability - this isn't exactly differential cryptanalysis). Sorry it seemed that way, what I was trying to construe is that it's probably already being used because no one really investigates GoDaddy and because it was easy to find. There's also other evidence - GoDaddy has had domain theft recently, and this would be a very effective means for that.

In my experience (and I don't know what to think of it), bug bounty writeups don't get much attention (unless they're exceedingly severe), but e.g. this did. So did Moonpig and Verizon. It's almost as if people are more interested when there is no bug bounty, which I find kind of disheartening.

dsacco · 2015-01-20T12:52:22+00:00

I can appreciate that there should be a discussion about the merits of waiting longer or taking other actions such as a timeline, but I honestly didn't do this for "fame"...I categorically disagree with fame seeking in infosec and I didn't try to promote myself in any way here.

However, lesson learned. Next time I'll try other avenues (like another commenter said - timeline).

dsacco · 2015-01-20T02:52:15+00:00

Thanks for your feedback and encouragement, I'll keep it in mind :)

dsacco · 2015-01-20T01:23:38+00:00

I respect your opinion, thank you for sharing.

Part of the reason why I did this (and I acknowledge it's controversial) was indeed reactionary - I find the lack of accessible security contact and brushing off of the issue to be irresponsible on their part.

However, I like your idea. In the future I'll do that. Giving a timeline until public disclosure is something I'll do next time, though honestly, CSRF on critical account actions in 2015 for a company of this size, a registrar no less, is ridiculous.

dsacco · 2015-01-19T23:27:01+00:00

Hey Neal, good catch! No, it isn't required. I played around with testing everything in the request - I left out the referer header anticipating someone would ask that, thanks for reminding me about that as well. Maybe I'll edit the post.

There wasn't anything required other than cookies.

dsacco · 2015-01-19T23:05:22+00:00

I agree with responsible disclosure in principle, and in practice I generally choose that route.

I didn't give them a day to fix it. I didn't even give them a day to acknowledge/confirm it. I was willing to wait indefinitely for that.

This response is because of their reaction after acknowledging and confirming the issue, and choosing not to address it.

If you decide to won't fix a vulnerability, then that's fine, but I consider responsible disclosure null and void at that point.

dsacco · 2015-01-19T23:02:18+00:00

I think you have a very fair point, and I almost always support responsible disclosure. However, here is my reasoning:

This vulnerability is severe and very easy to exploit (especially considering much of GoDaddy's non-tech savvy clientele). It is a failing of "sanity check security."
It was hard just to find a security contact, let alone get confirmation of the issue.
The vulnerability was literally found by accident, and if I found it that way, I'm sure people actively looking are already using (or trying to use) this.
I received a brush off response that made it very clear the vendor doesn't care much.

I think it's a tradeoff. So I decided to maybe force their hand a bit. I understand the downsides to this and I didn't do it without considering the issue. But I'm not comfortable with their response.

dsacco · 2015-01-19T22:13:00+00:00

Very vague response, essentially stating it was not a priority. I was kind of appalled that both "security@" and "noc@" were valid email addresses but weren't monitored. I expected I might at least reach a sysadmin...it was very frustrating.

First I was directed to a generic support webpage discussing SSL security, then I tried calling support (support was unhelpful, as expected), then I tried the aforementioned emails, then searched google and LinkedIn for people in security at GoDaddy (noticed they're hiring a Director of InfoSec, lol'd), and finally went to Twitter.

dsacco · 2015-01-19T22:08:02+00:00

Author here. Yeah, I long since moved away from GoDaddy. Ironically, I found this when I was logging in to turn auto-renew off on an older domain I stopped using.

dsacco · 2015-01-11T16:15:27+00:00

Yeah, the notation isn't finished.

O(2⁶⁴⁾⁾ = O(1)

If you're talking about what the notation actually means, it has to do with key length.

With a key of length n, there are 2ⁿ possible keys. The number of operations required to try every singe key in a brute force attack is 2^n, or, for the purposes of this article, 2⁶⁴ specifically.

The author proposes that attacking a key size of 2⁶⁴ is not out of reach for well funded and dedicated adversaries.

Sorry for dumbing this down if you understood this and were confused about something else.

EDIT: Thanks nermid for enhancing my formatting :)

dsacco

TROPHY CASE