Reddit Reddit reviews The Art of Software Security Assessment: Identifying and Preventing Software Vulnerabilities (Volume 1 of 2)

We found 18 Reddit comments about The Art of Software Security Assessment: Identifying and Preventing Software Vulnerabilities (Volume 1 of 2). Here are the top ones, ranked by their Reddit score.

Computers & Technology
Books
Computer & Technology Certification Guides
CompTIA
The Art of Software Security Assessment: Identifying and Preventing Software Vulnerabilities (Volume 1 of 2)
Check price on Amazon

18 Reddit comments about The Art of Software Security Assessment: Identifying and Preventing Software Vulnerabilities (Volume 1 of 2):

u/HockeyInJune · 20 pointsr/netsec

If you're talking about memory corruption, you're looking for Smashing The Stack in 2010. However, most experts in application security and modern exploitation techniques recommend a more practical research-driven approach to learning about memory corruption mitigation techniques, so keep that in mind while reading this paper. As always, The Bible is relevant.

If you're talking about embedded device reverse engineering, you'll probably get the best answer from the /r/ReverseEngineering subreddit.

If you're talking about kernel bugs and kernel module bugs, I wish you luck. Bugs and vulnerabilities in these types of systems, usually require very obscure knowledge in very specific systems. Not for beginners or the faint of heart.

If you're talking about web bugs, you're looking for the OWASP Top 10. The web is mostly a giant joke, and widely uninteresting (this is an unpopular opinion on this subreddit).

u/kobakai · 16 pointsr/ItalyInformatica

> Supponiamo che uno (anzi, più di uno visto che siamo tutti componenti di un LUG) voglia iniziare a smanettare un po' in quest'ambito, che cosa consigli?

di farlo :)

> Mettere su un webserver e iniziare a tentare di bucarlo con gli exploit conosciuti può essere una buona idea oppure è meglio prima procedere con altro?

Tutto fa brodo (mi', ventesimo proverbio, mi sto biscardizzando :). Però per prima cosa devono essere chiare le problematiche agli strati più bassi: boot da media esterno, forensics "malevola" (accesso al fs, reset delle password, estrazione delle password, trojanizzazione dell'OS, ..), MITM e i suoi derivati, poi nmap e network/service discovery come se piovesse, analisi di tutti i servizi esposti, poi "finalmente" potete dedicarvi anche alla parte (web) applicativa.. :)

Ci sono moltissimi "playground" per divertirsi ed imparare, sia come vm da scaricare che contest, crackme & co. online, alcuni al volissimo:

u/krenoten · 16 pointsr/netsec

Network security books are almost all scams that monetize the escapist fantasies of the fan base. Security is mostly assumption management. Don't assume a third party rehash is going to make you understand the underlying code any better.

That said, The Art of Software Security Assessment is pretty good. It's one of the books openbsd recommends for developers. It's quite healthy to know how anything talked about in the past 15 or so articles of phrack works, too.

Don't read anything that makes you think there is less for you to know after reading it. It's poison. And until you put the concepts into action, you don't know shit.

u/chickenfun1 · 12 pointsr/ProgrammerHumor

Web dev having trouble finding work? Buy this book and this book, read them and contact [email protected]

u/postmodern · 8 pointsr/programming

> They're wrong. The problem is that writing and testing cryptographic software is really, really hard.

Except that HeartBleed was an implementation bug, not a cryptographic one. It could have been caught if the OpenSSL maintainers a) paid for a security audit b) learned how to perform security audits themselves and did so on a regular basis. Instead of depending on security firms to audit OSS code, I feel this is an opportunity for the OSS community to unsilo the knowledge built up by professional security researchers and code auditors.

If you are interested in helping audit OSS C/C++ code, read The Art of Software Security Assessment: Identifying and Preventing Software Vulnerabilities.

u/PeeWeeHerming · 5 pointsr/AskReddit

Reverse engineer Microsoft patches.

edit: serious answer:

I do this kind of work for a living. I started out in 1995 when I was 13 years old learning from mudge's excellent article on how to write buffer overflows and I progressed from there.

If you're analyzing software for which you have access to source code, you can't beat The Art of Software Security Assessment: Identifying and Preventing Software Vulnerabilities.

Chris Wysopal's Art of Software Security Testing is also good.


If you're attacking software for which you have no source code, learn about fuzzing and reverse engineering. An excellent intro to reverse engineering is Reversing: Secrets of Reverse Engineering.

Those will get you started, but it helps to have people around you who are successfully discovering and exploiting software vulnerabilities. This is also the kind of field where you absolutely have to stay on top of the latest developments in software security. Things move at a mind-boggling pace. Read security blogs, talk to people in the industry, read books, etc...

u/joxeankoret · 4 pointsr/ReverseEngineering

"Source code fuzzers". Wow. Unless you're fuzzing a compiler/interpreter, it doesn't make any sense at all. Really, you should start by finding in Google about the subject.

In any case, I recommend you to read the book "The art of software security assessment" [1] and a Bug Hunter's Diary[2].

[1] http://www.amazon.com/The-Software-Security-Assessment-Vulnerabilities/dp/0321444426

[2] http://www.amazon.com/Bug-Hunters-Diary-Software-Security/dp/1593273851

u/px403 · 3 pointsr/blackhat

Also a classic is "The Art of Software Security Assessment"

http://www.amazon.com/The-Software-Security-Assessment-Vulnerabilities/dp/0321444426

u/rolfr · 3 pointsr/ReverseEngineering

Training or not, the only way to get good at it is to do it. When it comes to discovering and exploiting vulnerabilities in commodity software, I'd say there are four aspects: 1) knowing what constitutes a software vulnerability; 2) facility with vulnerability discovery; 3) facility with software exploitation; and 4) dealing with issues of scale.

As for 1), I'd suggest reading books on the subject (e.g., The Art of Software Security Assessment) and following conference presentations to learn about emerging trends. For 2) and 3), Capture The Flag challenges (e.g. /r/SecurityCTF) provide a font of both small targets to practice on as well as write-ups from people who have completed them. Also, follow blogs and conference presentations to learn about exploit techniques. This will help you only somewhat with 4), which is where having reverse engineering skills are especially helpful. 4) is a matter of experience -- trying to apply what you've learned from practice on smaller targets (like CTFs) to larger, real-world software, failing, and keeping at it until you start to succeed.

u/SHAGGSTaRR · 2 pointsr/netsec

The mother of all auditing books, better than Jon Erickson's jack of all trades - master of none approach imo.

The shellcoders handbook makes for an excellent accompaniment, too.

u/doc_samson · 1 pointr/cybersecurity

Based on reading some of your comments it looks like what you are really asking about is "how do I learn security engineering?"

The answer is by reading resources that explicitly teach the concept, because it is a specific discipline that blends software engineering, systems engineering, and computer security theory. It is probably most properly classified as a sub-discipline of systems engineering, so reading about systems engineering in general can be useful as well.

The following do not teach you "how to hack" they teach "how to look at this system/application from a security point of view" which seems to be what you are looking for.

Resources:

  • NIST SP 800-160 (read through Appendix F which covers tons of secure design principles -- dense but comprehensive)
  • Security Engineering by Ross Anderson is a phenomenal book and essentially the Bible of security engineering
  • The Art of Software Security Assessment is a great book I literally just found a few minutes ago that covers a tremendous amount of information on how to go about conducting application security audits (process to follow, technical key points to look for, threat model analysis, etc)
  • MIT Computer Security lectures basically an entire semester worth of lectures on how to think about security as an engineer

    Both of those books can be bought through Amazon or there are PDFs online. I have the first two and am now buying the last one after reading a bit of the PDF I found.

    Be warned, the last two books are very large. The second one would probably cover two semesters worth of material. The last one is nearly 1200 pages across two volumes.

    The MIT videos are great.

    Regardless of the above, Security+ or equivalent would give you a base level of knowledge from which you could get more out of the above materials. You can get Sec+ study guides online cheap/free, either in book or articles or video lecture form. Cybrary has great free cybersec lecture courses including Sec+.
u/Crimson_Steel · 1 pointr/coding

For those looking to write and/or evaluate the security of software, there's also TAOSSA.

u/horstenkoetter · 1 pointr/netsec

A little prophecy here - neither WebInspect nor Fortify will actually solve any of your problems, they'll just point you at them. Having bug reports doesn't mean the issues get solved (correctly), and to get the ones which actually matter you'll have to wade through lots of false positives, even with the better tools.

In order to determine what counts and what doesn't and how you fix it if it does, you actually need security competence. Which is something the developers who are often facing hundreds or thousands of bug reports from these tools often do not have, since they were never trained and/or had no time to further look into.

When it comes to pen testing and app sec assessments, it really depends on what you're looking at. If it's web apps mostly, well, I am sure you already know OWASP. I kinda liked the Web Application Hacker's Handbook.
When it comes to other stuff, this is a great book http://www.amazon.com/The-Software-Security-Assessment-Vulnerabilities/dp/0321444426

I am, btw, a CSSLP, and I think the cert is kinda fluffy.

u/KevinHock · 1 pointr/netsec

Senior Security Engineer

Hi, I'm Kevin Hock and I work on the DataDog security team.
We are looking for some talented security engineers to join our security team here in NYC.

How Do I Apply

Send me an email with your resume and GitHub at [email protected]

What you will do

  • Perform code and design reviews, contribute code that improves security throughout Datadog's products
  • Eliminate bug classes
  • Educate your fellow engineers about security in code and infrastructure
  • Monitor production applications for anomalous activity
  • Prioritize and track application security issues across the company
  • Help improve our security policies and processes

    Who you should be

  • You have significant experience with network and application security
  • You can navigate the whole stack in pursuit of potential security issues
  • You want to work in a fast, high growth startup environment

    Bonus points

  • You contribute to security projects
  • You're comfortable with python, go and javascript. (You won't find any PHP or Java here :D)
  • CTF experience (I recommend you play with OpenToAll if you don't have any)
  • Program analysis knowledge

    Sample interview questions

  • Flip to a page of WAHH, TAOSSA, CryptoPals, ask you about it.
  • Explain these acronyms DEP/ASLR/GS/CFI/AFL/ASAN/LLVM/ROP/BROP/COOP/RAP/ECB/CBC/CTR/HPKP/SSL/DNS/IP/HTTP/HMAC/GCM/Z3/SMT/SHA/CSRF/SQLi/DDoS/MAC/DAC/BREACH/CRIME?
  • How would you implement TCP using UDP sockets?
  • How do you safely store a password? (Hint: scrypt/bcrypt/pbkdf2)
  • How does Let'sEncrypt work?

    Hat tip to Levi at SquareSpace, also on this thread, he is an awesome person to work with. David Wong, a crypto king of NCC, on this very Q4 thread, is also a great person to work with in Chicago.
    If you're looking to break stuff more than build stuff hat tip to Chris Rohlf's Yahoo! team.
    Random other places you can apply in nyc: MongoDB, Jane Street, 2 sigma, greenhouse.


    I personally applied because I love Python but I like the company a lot so far.
u/cHoco- · 1 pointr/ReverseEngineering

I'm in a similar situation and some resources that I'm finding really eye opening are Trailofbits CTF Guide and the book [The Art of Software Security Assessment: Identifying and Preventing Software Vulnerabilities] (http://www.amazon.com/The-Software-Security-Assessment-Vulnerabilities/dp/0321444426).
I also find other people exploits and presentations inspiring in a sense :)

u/joatmon-snoo · 0 pointsr/explainlikeimfive

Your recommendation for AV is wrong: antivirus software generally makes your computer more vulnerable.

Where am I getting this from?

  • Justin Schuh, the Chrome browser security lead and a co-author of The Art of Software Security Assessment, which I'm told is the bible of its subject,
  • April King, an infosec engineer on the Mozilla Cloud Services with a hand in Mozilla Minion and Firefox, and
  • Tavis Ormandy, of Google Project Zero and whose name you can't not recognize if you follow any security news at all (he's found vulnerabilities in - to name a few - Symantec and Norton AV, as well as Dashlane, 1Password, and Lastpass).

    James Findley has a nice post over at Hacker News which, in my non-expert opinion, sums up the state of AV well:

    > In the days of windows 95/8, the desktop landscape was very different to how it is now - OSes and browsers were horribly insecure, and readily compromised with little effort. Attacks were plentiful, and infections common. AV really did add useful additional security.
    >
    > These days that's less the case - an up to date windows 10 or OSX desktop is reasonably secure by default - it can still be infected, but generally not without some action taken by the user (of course there are still 0-days, but they are generally treated seriously and patched at least moderately quickly. Unauthenticated RCEs are now a rarity, thankfully).
    >
    > The AV industry hasn't really caught up with the idea that the OS/apps they are messing with are now in general fairly well written and audited pieces of code, and haven't really got institutional awareness that they are making things worse, much of the time.