- This topic has 24 replies, 7 voices, and was last updated 9 years, 10 months ago by
.
-
Posts
-
This is it! The place you can ask anything you like about Application Security, or presenting at EuroSTAR as a first timer. Whatever comes to mind after joining the EuroSTAR webinar of the same name. Don’t be shy, assert yourself!
View the Webinar Recording & Slides Here
Thanks for the intro 🙂
as there were the 11 pages – what else asside OWASP sites you could suggest to explore more? 🙂
and.or – what books would you suggest that would help to grasp APP SEC 🙂
thanks 😉-^. ^=-
~~ ~~i missed the name of the guy who was bench-marking the tools 🙂 could you post it here as well 🙂
-^. ^=-
~~ ~~Ah Go To Webinar, never a dull moment with that technology but hopefully you guys got the message!
I always try to get all members of the project team to read through James Bach’s Heuristic Test Strategy, as for the most part I will never have worked with these team members before . This is what it states for Security.
Security. How well is the product protected against unauthorized use or intrusion?
* Authentication: the ways in which the system verifies that a user is who he says he is.
* Authorization: the rights that are granted to authenticated users at varying privilege levels.
* Privacy: the ways in which customer or employee data is protected from unauthorized people.
* Security holes: the ways in which the system cannot enforce security (e.g. social engineering vulnerabilities)Would you add anything to this?
ALSO
What are the usual ‘Quick Wins’ where a difference can be made quickly?
There are many, many things to read on application security! If you want to become a typical security person the books by Shon Harris set the gold standard for certification. Unfortunately that is the book with only 11 pages on application security. It is ten miles wide and two inches deep, although Shon was a great woman and security author nevertheless. The ISO 27001 standard is also the typical industry attempt at an Information Security Management System. There are also useful books on Threat Modelling although that opens up another can of worms!
If however you want to build secure web applications I’d recommend all the OWASP guidelines, The Web Application Hacker’s Handbook, The Browser Hacker’s Handbook, The Android Hacker’s Handbook, The iOS Hacker’s Handbook, The Oracle Hacker’s Handbook, The Shellcoder Hacker’s Handbook, plus a load of news sites that I’ll list in a moment!
Hi Stuart, I have great respect for James Bach but what I could add to that would take thousands of pages! If you read my eBook when it is released by EuroSTAR, the appendices will give you an idea of ‘The anatomy of a criminal attack’ and a simple breakdown of Authentication, Access Control, and Session Management testing in terms of what can be done by ‘normal’ testers and what needs skilled experts (until their skills are transferred into the project teams).
As I said in the webinar, testing is a small subset of application security not the other way around!
Hi Allan, I’ve made my whitepapers available for free on my company’s website: http://www.testandverification.com/solutions/security/security-whitepapers/
These are my refinement of the OWASP material into a more manageable size. I couldn’t make the Application Security Testing Procedures or Development Guidelines any smaller without omitting something important. The OWASP material is great but there is just so much of it!
Hi Alt,
Here are some useful links for starting to learn application security:
https://www.owasp.org/index.php/Category:OWASP_Testing_Project
https://www.owasp.org/index.php/Top_Ten
http://blogs.microsoft.com/cybertrust/2014/04/15/introducing-microsoft-threat-modeling-tool-2014/
https://www.owasp.org/index.php/Threat_Risk_Modeling#Performing_threat_risk_modeling_using_the_Microsoft_Threat_Modeling_Process
http://www.sectoolmarket.com/price-and-feature-comparison-of-web-application-scanners-unified-list.html
http://cwe.mitre.org/documents/vuln-trends/index.html
https://cve.mitre.org/cve/index.html
http://www.forbes.com/sites/frankbi/2014/12/19/live-map-shows-thousands-of-cyber-attacks-as-they-happen/
http://www.xenuser.org/xss-cheat-sheet/
http://krebsonsecurity.com/
http://grahamcluley.com/
http://www.troyhunt.com/
http://www.scmagazineuk.com/news/section/314/
http://en.wikipedia.org/wiki/Tor_(anonymity_network)From personal experience I’d say teaching yourself App-Sec is a lot harder than getting some coaching or training to set you off in the right direction within the context of your systems and to answer your questions rather than you always have to research them. I’m living proof it can be done, and if you can get someone like me to provide you with app-sec coaching you will learn faster and more efficiently. If you can’t get the budget for that do not despair, whatever you can teach yourself will improve your confidence in dealing with security experts and getting pen-testers to work in a targeted, properly managed fashion.
Good luck!Hi ,
I miss two names in the messages above: James Whittaker and Bruce Schneier.
The books by James Whittaker are very practical / hands on, the books by Bruce Schneier are mostly on a higher level of abstraction.
A lot of hacker sites have good information on application security. For some of those you need to be certified (i.e. CEH) others are freely available and sometimes a little on the dark side.Hi Kasper, the reading list was by no means comprehensive and yes I’d certainly agree Bruce Schneier is highly influential. Regarding James Whittaker’s 2003 book, let’s agree to differ!
Hi Declan, I agree to disagree although you sell Whittaker short by only looking at the 2003 book.
“How to break software” is a good primer to change the mindset of the “normal” validating tester and “How Google tests software” is a very comprehensive take on the subject of testing by Google.
My 2 cents.Hi Kasper. It’s a few years since I read that. Wasn’t he proposing getting rid of testers and finding the bugs in Beta releases and Production? Nice if you are Google but not everyone is. I guess I am biased because I think he was responsible for testing Microsoft Windows Vista and that was a load of crap. Please correct me if I’m wrong!
Hi,
Can you share your view on App-Sec with prioritize security issues (internal and external threats.)
Hi Declan, James Whittaker was at MS at the time of Vista but as Security Architect.
I don’t like most products coming from MS (with the exception of Flight Simulation – by now discontinued by MS) but if I followed your reasoning I would not take James Bach, Michael Bolton or Cem Kaner (to name a few) seriously since they all worked for Miicrosoft around the time of Vista.
I never heard or read Whittaker take the stand to get rid of testers, but I could be wrong – I have not read everything he wrote and surely have not seen all his presentations.Hi Kasper, You raise many important questions there. I fundamentally disagree with applying the Google / Microsoft philosophy of letting the users find most of the bugs, if that is what they are intentionally doing. I switched to buying Apple after the Vista disaster. I’m very busy at the moment reviewing about 450 EuroSTAR submissions and will try to look up James Whittaker’s statements on the subject in a couple of weeks. I think EuroSTAR published an eBook by him about three years ago. If you have time please search for it!
Actually Kasper, I just found an extract of his eBook right here in the test huddle. Here are a couple of sections that caused me to form my opinion (right or wrong):
“Because the number of actual dedicated testers at Google is so disproportionately low, the only possible answer has to be the developer. Who better to do all that testing than the people doing the actual coding?”“One of the key ways Google achieves good results with fewer testers than many companies is that we rarely attempt to ship a large set of features at once. In fact, the exact opposite is the goal: Build the core of a product and release it the moment it is useful to as large a crowd as feasible, and then get their feedback and iterate. This is what we did with Gmail, a product that kept its beta tag for four years. That tag was our warning to users that it was still being perfected. We removed the beta tag only when we reached our goal of 99.99 percent uptime for a real user’s email data. We did it again with
Android producing the G1, a useful and well reviewed product that then became much better and more fully featured with the Nexus line of phones that followed it. It’s important to note here that when customers are paying for early versions, they have to be functional enough to make them worth their while”Hi Padmaraj,
Unfortunately there isn’t a single answer to your query. Verizon published some good research on this last year. They found Internal threats to be highest in real estate but overall the insider misuse problem seems to be on a low plateau, probably due to adequate access controls and ISMS disciplinary procedures. Interestingly, most insiders discovered in wrongdoing commit the crime while working out their notice to leave.
The external threat leads to more breaches in most published research. To understand the specific threats to your enterprise you would need to undertake a threat assessment and design prioritized controls to mitigate the realistic threats. Security testing then validates those controls are effective. Take a look at the Microsoft STRIDE threat modelling process if you’re starting from zero. It doesn’t scale well, particularly if documentation is lightweight and non-standard across projects, but it’s a useful approach to consider.
Best regards,
DeclanOh and Padmaraj, I forgot to mention the insider threat includes third-party and open-source developers. They are more dangerous than the obvious insiders.
Hi Declan,
The quotes are indeed from How Google tests software, but without the context (of the book) they are more provocative then insightful.
I guess discussing the book is outside the scope of this thread, but we can always continue the discussion offline 🙂
- You must be logged in to reply to this topic.