Spend time to dive into the development framework or security documentations that you are not familiar with.
Do it everyday consistently in an allocated time.
Understand the Framework hardening guideline. Study the framework security docs.
I just dedicate half an hour to an hour every day to exercise and to study a little bit, and I still get my other work done. It’s a discipline, and there’s no easy answer John. That’s the best. I think, unfortunately, you’re exactly correct.
Jun 8, 2023 Presenter: Tanya Janca, CEO and Founder, We Hack Purple
Recently I watched a talk from Tanya Janca on DevSecOps worst practices. The talk is interesting because I have seen similar practices during the early adoption stage of DevSecOps processes and culture. If you find that your DevSecOps practices have plateaued, chances are that your program is practicing some of the bad practices.
Below is a list of bad practices mentioned by Tanya:
Breaking Build on False positives
Turning on a tool without testing
Artificial Gates
Missing Test Results (Results are not shared in a convenient location)
Missing Runway Testing (Not testing the tools in the CI pipelines to see the job duration impact)
Impossible SLAs
Untrained Staffs
Bug lost in Backlog
No Positive Reinforcement
Only worrying about your part (Not understanding whether another teams are facing any issues if you make the changes)
Multiple Bug trackers (Bugs tracking are scattered in different dashboards)
INSecure SDLC (Tools are not enough. We need more process and other activities like Threat Modelling)
Overly Permissive CI/CD (Skipping a process to deploy to prod)
Automation only in CI/CD
Hiding Mistakes and errors
I will only highlight a few of these practices and share my thoughts.
Turning on a security tool without thorough testing
Testing a new tool for effectiveness is HARDER than we think. Usually POC on a vendor product has a limited timeframe (about one month plus). And you need to identify the teams that are suitable to test the products. If you chose the wrong team to test the product, you might jump into conclusion that this product is bad. Or if you test it on only subset of team, we still find it uncertain if the performance can be replicated to other teams who are using a different tech stack.
Tanya mentioned that one way we can do is buy perpetual license and trial it for about 6 months before deciding to purchase a larger contract. I think this is a good recommendation.
From vendor point of view, you should think about how you can let the security team try the important features of product and test it sufficiently so that they can make better conclusions.
Overly Permissive CI/CD
Tanya gave an example about how the development team can disable tests in order to deploy to production. If too much permission is given to the team, some might abuse the permissions to reach their goal.
In general, I think CI is a wild jungle where you can run any scripts or workflows. But the crucial thing is to restrict the permissions for deployment (CD). If we control the permissions better, we can stop people from abusing deployment rights.
Impossible SLAs
In some organizations, there are strict SLA requirements for deployment to production. For example, there can be a SLA that “NO CRITICAL or HIGH” issues in production.
This might be impossible to meet for some of the teams (Especially if they have legacy apps). Tanya recommends that Security team should consult other teams to see if this SLAs is feasible. Listen to see if the teams can fix the issues to meet the SLAs.
Information Security is a broad field with many specialties such as Infrastructure Security, Cloud Security, Container Security. DevOps automation and Application Security (Source Code / Design level) etc. In real life context, an Application Security may need to focus on a few specialties since modern applications are using Cloud PaaS / IaaS and Containers.
Since there are so many specialties to learn, you may get overwhelmed by the knowledge and how to apply what you learn on the actual context. I read an interesting Div0 post on a cybersecurity career discussion panel on this topic:
Many aspiring cybersecurity practitioners say they are passionate about cybersecurity. But they have no work to show/prove their passion. Don’t just say you are passionate. Do it, show it!
There’s no shortage of aspiring cybersecurity practitioners who want to learn. However, there’s a lack of drive on how they can contribute to the organization. Continuous learning in a fast-moving industry like cybersecurity is important. However, you should also focus on how you can apply your skills (emphasis mine).
Cybersecurity is not just about technical skills. In fact, picking up technical skills is the easy bit. Shaping your attitude and mindset in how you deliver the promise your clients entrusted in you plays a much bigger role.
An essential characteristic to have in the industry is Grit — the passion and sustained persistence towards long-term achievement.
In a wide discipline like cybersecurity, it is important to collaborate and bounce ideas with fellow practitioners — that’s how you push the boundary.
The mad rush to get all the fancy certifications is not healthy. There’s no point being certified but you still can’t get a complete grasp on security controls or even the fundamentals. Focus on building up your skillset, not the alphabets behind your name.
Often Application Security new joiners have to learn development skills on their own projects if they are not joining from development background. They may be pentesters, sysadmin, DevOps engineers or career changers coming from another field. Each of them have their own unique perspectives.
You need to understand development but…
If you see in many Application Security job descriptions, many companies require development background. This requirement ensures that you can empathize with the development team that you will be working closely with.
Be careful not to become too developer-like because you will lose independent assessment since you are too close to the development team. For example, some developer tells you that this SQL injection is not a risk since the string values come from hardcoded config file. If you get too close to dev team, you might accept the risk without pointing out additional caution.
However, from another independent perspective, this means that SQL injection can happen if a rogue developer / QA / devops change the config file to a SQLi payload. The long-term solution is actually to use parameterized query and prepared statement even though the values are hardcoded. However if you get too close to dev team, you will start to feel their pain and deadlines if the feature is not released on time. So you might not even suggest the team to pick a more secure approach. Or you might ask the team to add this suggestion to backlog. It remains to be seen whether the safer approach will be adopted since there is always another new feature to complete.
Security Champions might also struggle to give independent assessment especially since they are part of the dev team. Moreover, many of them are developers or QA and have deadline and user stories to complete as well. Therefore Security Champions cannot do it alone and need pairing with the internal Security SME to give a balanced assessment.
On the other hand, you are too far from the development team, you will start suggesting crazy security activities from some PDFs or slides that will never gain any traction with the development team. Many good ideas sound great in powerpoint slides but difficult to gain traction in practice because real world has more decision-making factors in which security is just one of them. You need to at least understand some of these major factors such as business risk appetite, ROI, regulatory requirements etc.
Not enough to learn Development
To understand Application Security in depth, the newbies have to pick up coding and software development concepts such as MVC etc. on their side projects or on the job. It will take time and requires a lot of experimentation, readings, note-taking and questioning.
You shouldn’t just learn coding like watching a Udemy course on Web Development or Mobile Development. After all, your job also consist of the security aspects of delivery. Most of the development courses will not mention Application security topics. This means that you need to create your own contexts to apply every topics that you have watched on Application Security.
An example of I apply newly learned security knowledge to coding
Recently, I attended an online webinar on building secure React applications. This is an informative talk with hands-on examples that I recommend people to watch.
My first thought is to find the React code that I wrote on my own.
Previously, my understanding was that ReactJS is secure by default library and XSS is difficult to achieve unless developer use dangerouslySetInnerHTML. But from the video, I updated my understanding of ReactJS and recognized more XSS attack surface.
Then I tried to modify my React component code to create the XSS vulnerability. Imagine the developer thinks that getting the name from props is safe to use in href.
But if the attacker include JavaScript url, then there is a stored XSS issue.
From now, when I look at ReactJS code, I will also include such checks in my code review methodology. Or when I am looking at ReactJS app, I will be more awareness of more things to look out for such as hrefand srctags etc.
Note that this a collection of tweets about DAST (excluding any specific company pitch). In general, it seems like many companies are unable to utilize the potential of DAST yet because of limitations in most of DAST tools. This opens up opportunity for people to create new DAST tool to overcome current problems.
Summary
Many AppSec folks are struggling to get any real value out of commercial DAST tools. Many problems include tools being unable to record Authentication properly and test coverage issues.
OWASP ZAP and Burp Enterprise Scanner are popular tools used in DAST automation in DevSecOps pipeline.
Some AppSec folks are proxying their QA stage to ZAP or Burp in order to improve test coverage of DAST scan.
“DAST biggest issue in modern apps is not exactly ‘testing’ or even ‘detecting’ vulns, but crawling the same website to identify to the attack surface.” ~ Jeremiah Grossman
OWASP Attack Surface Mapper tries to use SAST to pre-seed attack surface for DAST scan.
Interesting Tweets about DAST
Decide what ROI looks like and make sure the tool meets your expectations. If your apps are complicated might be hard for DAST scanner to cover them properly. Not convinced I have ever seen a company get real value out of DAST. Maybe just make sure your pentester is uses Burp/ZAP
— Josh Grossman 👻 (tghosth) (@JoshCGrossman) June 4, 2020
I have experience with Netsparker, and. Wracked DAST. Honestly, depending on your environment and whose managing the tool I’d just go with BurpSuite Enterprise. DAST is fairly limited anyways.
This maybe controversial, but another point that came up w/ @clintgibler is that orgs are having trouble seeing value of DAST tools. Suspect coverage, problematic depth, FPs, and a high price tag make ppl think twice. #appsec
This talk gives some examples of why good DAST coverage on modern web apps is fundamentally hard: https://t.co/pL4AWlCgQy
Many companies using C/C++ are adopting fuzzing, which is 💯@thedavidbrumley Do you think fuzzing provides value for non-C/C++ repos e.g. Python, Java…?
Coverage isn't the goal. Finding real bugs is. And if an automatic tool can increase your code coverage by 20% without having to resource a developer to do it, that seems like a win (that static analysis can't do).
I have long wanted to setup burpsuite to be the proxy for all tests used for QA and then allow it to run the attacker mode. Now that they have a headless option, I wonder how it would do. Since QA is likely hitting most endpoints, the tool knows endpoints and params to fuzz.
I know a number of AppSec teams have tried proxying integration tests through Burp then fuzz/attack mode, and found that it provides at least some baseline coverage.
Won't necessarily help with multi-step flows, but might be worth playing with.
Noooooooo you can't just point a DAST tool at a modern web application and expect it to be able to find all the content and test it for complex vulnerabilities
But they've been doing that for 15 years. Still none that I've seen actually do a good job of injesting and merging data from outside their tool (i.e. pen-tests, DAST tools, RASP tools, etc). Its frustrating because I've seen so many refer to running scans as their VM program.
— Alyssa Miller (Speaking at All Things Open) (@AlyssaM_InfoSec) May 14, 2020
I disagree. DAST is not perfect, but as it is often the last check prior to going live, it is hugely impirtant. If your company uses manual testing, that could be an alternative. As far as cost, use the popular open source tool #OWASP ZAProxy https://t.co/8ba6UDZdUN
IAST can give some of the benefits of DAST when used in the pipeline. You get speed but can still miss out on the coverage of DAST. You can "fail forward" by pushing to production after passing SAST&DAST scans and then run an asynchronous DAST scan and fix issues on next deploy.
That says that you don't know that your tool has failed you. It has. Did it fail to scan a SPA because it couldn't read routes? Did you have one where authentication stopped working and it ran for a week unauthenticated? Did your DAST tool ever find an IDOR vuln? 5/16
Previous oodles of data (defect densities, "what finds what", & measures related to remediation) lead me an opinion:
Activities (i.e. DAST, threat modeling, or tool du jour) don't tie directly to effectiveness. Effectiveness results from combining activities into capabilities.
Wonder why Vuln Management sucks? A test scan of 14 hosts with NO critical vulns takes 1hr+ and results in … a 571 page PDF. FIVE HUNDERD SEVENTY ONE PAGES???? This is insane. pic.twitter.com/R65KpTNIx6
It's more that the appsec toolsets themselves are integrating into the sdlc as it exists today (highly iterative), so SAST/SCA built into the IDE, invoked at check in, etc…DAST/IAST running continously in test or kicked off by a build tool, etc.
Whenever DAST vendors hmu I tell them to create a segment account (free), run their tool, send me the results, and if they're good we can talk. So far nobody has done this, not sure if it's because their results are bad or if they just aren't even trying.
I think it depends on the team. In my experience, some only want to make sure that the DAST tool doesn't log a new finding for every time a scan is run, others do want it to be collapsed. I know devs love smaller tickets, so something with 53 things to fix across all code…
DAST is meant to find vulnerabilities that adversaries may exploit. SAST is meant to find those same vulnerabilities earlier in the SDLC — but does it really? What’s the best data-backed evidence available in order to support or refute this claim? My search results are sparse.
When evaluating DAST vendors we struggled to find one that could authenticate to our app, and those that did limped through spidering. That sector has not kept up with single-page React apps.
A novice bug bounty hunter with Burp is the new DAST.
Proxying your acceptance tests through ZAP (or Burp) provides it with surface area for attacks. I agree, it's hard for these tools to get the full grasp of the surface area. That's why it's important to use a tool that is flexible & scriptable
DAST is anything but useless. For example it's tremendously helpful in complex application where the relationships between "code actually run in the browser" and "code in the repo" is anything but obvious. That's most modern apps.
This is an interesting tool, which used the power of SAST to feed DAST tools. Thinking about it – isn't the same as using OpenAPI/Swagger to feed DAST tools? What is the difference? https://t.co/v0aMD0rlgP
1. The Tool – What is/are the tools that map to the target tech stack 2. Deployment environment – Are scans intended for Dev, Integration or Staging 3. Time – How much time can be spared within the release cycle
Any one tool for API analysis is incomplete. A combo of IAST, DAST, Swagger, Manual investigation and other tools is what I see most mature shops (with good risk management) doing.
It's probably high time we saw some decent comparative analysis of DAST products, unless there's already some out there. There's room for everyone in the space, I think, but I also think it would be worth a look at the different qualities.#AppSechttps://t.co/DU30agOqDD
IME, highly depends on DAST training and complexity of target being analyzed. Scan blind and go will result in most vulns being found by SAST. If you train DAST through selenium, swagger, and proxy logs, the two will relatively even. Neither will detect biz logic flaws.
My only concern with ZAP is if junior level AppSec engineers will be able to set it up, embed it into the CI environment, parse the results and provide enough info to sw dev teams (attack replay) to fix the issues found. Thoughts?
I've been anecdotally tracking the effectiveness of DAST (web app security scanners) for years. @Burp_Suite 's active scanner and @ArachniScanner are still my 100% front-runners.
Ayup. DAST biggest issue in modern apps is not exactly ‘testing’ or even ‘detecting’ vulns, but crawling the same website to identify to the attack surface.
Proxying your acceptance tests through ZAP (or Burp) provides it with surface area for attacks. I agree, it's hard for these tools to get the full grasp of the surface area. That's why it's important to use a tool that is flexible & scriptable
Attack Surface Detector (ASD) Provides complete picture of web app’s exposed attack surface. Output used to “pre-seed” DAST tools for more thorough pen testing. Plugin available in the Portswigger Burp BApp Store. Download https://t.co/D48XBeAGHc@Burp_Suite@BApp_Store#PenTest
There is a lot of potential for product security teams to write passive/active scanner checks to avoid regressions or cover similar vulns – however the number of companies having dynamic testing as part of the CI/CD is still too small
These problems are not unique to Burp. The DAST market is wrought with products that can't handle modern application architecture, and I don't know of a single one that can. They are trying to accomplish a near impossible task. (5/10)
DAST solutions simply cannot effectively discover modern applications, and even if they could, cannot analyze with the context that is needed to discover authentication, authorization, session management, and business logic issues. (8/10)
Slow feedback loops in SAST, DAST, penetration tests, etc. things that force a leftward movement (a reset) in the pipeline are the problem. Feedback must be immediate, and the path for getting the feedback has to connect with the developer's existing environment. /FIN
— Alyssa Miller (Speaking at All Things Open) (@AlyssaM_InfoSec) September 16, 2020