Fantastyczne środowisko do nauki testowania bezpieczeństwa aplikacji webowych

Testy bezpieczeństwa aplikacji webowych są dla wielu wejściem w świat bezpieczeństwa – i słusznie, to przyjemna specjalizacja o całkiem niskim poziomie wejścia.
Wobec tego, często pojawia się zapytanie o to od czego zacząć, gdzie pohackować i nauczyć się praktyki. Do tej pory, moimi ulubionymi zasobami, które polecałem były wirtualne maszyny tworzone przez społeczność OWASP, hackthebox i inne CTFowe cudactwa.Teraz chciałbym jednak podzielić się z Wami czymś co wygląda fantastycznie, dostarcza instrukcji krok po kroku i jest regularnie aktualizowane i rozszerzane.
Mowa o (darmowej) Web Security Academy stworzonej przez firmę PortSwigger,
twórców narzędzia Burp.

Już kilkanaście osób dało mi na priv znać, że akademia jest bardzo przystępna dla ludzi stawiających pierwsze kroki w świecie bezpieczeństwa, jak i dla developerów którzy chcą poduczyć się jak tworzyć bezpieczniejsze aplikacje.
Będąc doświadczonym pentesterem czy bug hunterem raczej szczęka Ci nie opadnie, ale mi opadła w kontekście tego jak wygodne jest to narzędzie to nauki.
Logujesz się, klikasz na ‘access lab’ i w kilkanaście sekund dostajesz wygenerowaną indywidualnie aplikację do zabawy online.
Więc jeśli ktoś się do tych grup zalicza, lubi ładnie zaserwowany fun, to polecam rzucić okiem na któryś z kilkudziesięciu labów. Ja personalnie mega się cieszę, że w obecnych czasach ludzie chcący nauczyć się bezpieczeństwa mają tak przystępne materiały, które ładnie wyglądają, konkretnie tłumaczą temat i najzwyczajniej w świecie skutecznie działają.
I dlatego szeruję, bo darmowa wiedza o takiej jakości to rzadkość i zasługuje na docenienie.


Jeśli ktoś korzystał – dajcie znać co sądzicie.
Z pozdrowieniami na fantastyczny 2020,

Praca zdalna nie jest dla każdego – o niespodziewanych konsekwencjach wieloletniej pracy zdalnej w IT

Od wielu lat jestem fanem pracy zdalnej i często polecam ludziom, którzy tego chcą – żeby spróbowali swoich sił. Bo wrócić do pracy w biurze zawsze można, i ja dziś właśnie o tym powrocie do pracy w biurze chcę opowiedzieć, po tym jak przekonałem się, że bardzo łatwo jest się zatracić.

Więc tym razem opowiem o niespodziewanych negatywnych konsekwencjach wieloletniej pracy zdalnej w IT, o zdrowym zarządzaniu swoją karierą i efektywnym zarządzaniem kadrą pracującą zdalnie.

A co ze mną?
Ja jestem pewien, że z obecną wiedzą życiową i ucząc się na błędach, na pewno wrócę jeszcze do pracy zdalnej i będzie świetnie – ale na to jeszcze nie pora.


What makes and breakes DevSecOps culture – video from SecureGuild 2019

Earlier this year I was asked to prepare a presentation for SecureGuild 2019 – an online conference focused on application security.

I’ve decided to take it a bit further and instead of talking just about appsec, I showed up with a presentation about DevSecOps and my real-life experience with it. I felt like there still isn’t enough content released for the community to learn from individual cases.

The main theme of my talk was how to achieve a successful DevSecOps evolution through realistic expectations and company-wide transparency and here is how I summarized the talk:

Although most companies are somewhere in the middle and it’s hard to really determine the factors that allow them to effectively manage their security operations, there is a lot we can learn by studying the stories of companies that thrive on DevSecOps and those that really struggle to make it work. In my experience, the biggest reason for companies failing to succeed with DevSecOps is that instead of embracing it, they engage in the project with deep resistance because they know they haven’t really done their homework and aren’t prepared enough to comprehend the big-picture perspective. During my presentation, I want to share with you my observations from over 5 years spent in the trenches, which should turn helpful if your goal is to build a DevSecOps roadmap that focuses on practicality and positive long-term influence at your organization.

The video was originally published in May 2019, and I’ve received a confirmation from the organizer that I can release it to the community in December, so here we go!

I hope that my research and experience help the community a bit. Curious to hear your stories on the experiences you’ve had with DevSecOps and DevSecOps-wannabe organizations.

All the best,



Useful training and mindset for becoming a Cloud Security Architect

A couple of weeks ago I was asked by my colleague to give him some clues and tips on how to become a Cloud Security Architect, as that’s the venture he wants to follow and he knows I’ve been in architect-alike roles for a while.
Knowing how much fulfillment one can get from a good career and work-life, I’ve had decided to sit down and write down some tips right-away. I did share it with him, but then I’ve had looked at it myself and I’ve come to realize that instead of a few tips, I happened to write a lengthy article on the subject. So I’ve polished it a bit and wanted to share this with you.

Please note, that I’m never in this article claiming that this is the ideal path, the only path or anything of that nature.
I’m no guru, no career expert or some crazy good security architect.  I’m just a dude who happened to manage to get to the point I’m right now, and I want to share my perspective as a mean to help you see the journey of others and maybe get some clues on how to proceed with your career.

To me, the role of a security architect is as much about technical work as it is about business and leadership. While the specifics of the role definitely vary between companies, it’s a common requirement for architects to know how to talk to C-level executives, lead teams and independently manage the workload in such as way that the project gets delivered in compliance with the business requirements. Sometimes reading through the job descriptions you may get the impression like the productivity of a security architect equals their social-savviness and there is something to it. Rarely you can build great things without the involvement of great people and if you can’t influence them to follow your leadership, then you’re missing out on a huge potential of the group work.  But I published a whole book on how to level up your social skills game to boost your career in infosec, so I’ll skip that and will focus on other aspects of the role.

My path isn’t obvious but it’s very common

In my case, I can’t really speak of any certifications or training aimed at becoming a security architect – if you know some, please leave a comment with some about it – but I have completed a bunch of Cloud Security Architecture related courses and training, which I believe helped me tremendously in getting better.

I haven’t had any formal education that got me into the role of a security architect, but rather a lucky series of opportunities that presented themselves in front of me and I was able to get hold of them.
To cut it short, I’ve started gaining exposure to the commercial IT about 10 years ago. I’ve started as a programmer, then became a network administrator(netops), sysadmin, bug bounty hunter, pentester, offensive security engineer, security engineer working in a blue team focused on SOC/IR. During that time I’ve been focused on self-development to mature – as each human should – both in personal and professional life. I’ve made sure to keep myself educated on business, social dynamics, relationships and all types of things, to get more context and wider perspective. It took quite a while, but I feel that the appreciation to the challenges faced by people on different roles and different levels of seniority eventually made me a better security architect.

Like I’ve said earlier, education never stops because you always learn new things on the go and try to be prepared for new projects. To stay as current as I can in this fast-paced industry, I try to take advantage of the content shared by people generous enough to share their knowledge. I can’t really express the level of gratitude and admiration I have towards people who’ve had done something and then have decided to share their knowledge on the Internet. You can really, really learn a ton by following what others have tried, what they succeeded in as well as what they’ve failed at. Each lesson holds enormous value, regardless of it’s a study of the success of a failure – you’re focused on studying somebody’s attempt and then deciding on how you can put that knowledge to use in your particular real-life scenario.

Recommended technical training for Cloud Security Engineering and Architecture

When it comes to the cloud I’m really a fan of vendor-specific training and certification, because due to the complexity of each of those environments, the generic training just doesn’t cut it.
Vendor-specific training allowed me to much easier navigate through the piles of knowledge I’ve collected along the way while playing with various environments on different projects and helped me put a solid structure around the knowledge I’ve had from reading blog posts, articles, podcasts and whatnot.

All of the leading cloud service providers – Google, AWS and Azure – have fantastic training and certifications that prepare you for hard scenarios you’ll face in real life. I’d say that before the training I’m about to mention, I used to cope with the security in the cloud and each and every next training made me feel like I’m more thriving in those environments rather than fighting each day and stressing about every little thing, dreading the unknown.

After having a few years of average-quality experience in playing with various cloud environments, I took enormous value from signing up for the following training which I’ve completed over the years:

Google Cloud Platform(GCP): 

Google Cloud Professional Cloud Architect
Google Cloud Professional Associate Cloud Engineer
Google Cloud Professional Professional Cloud Developer
Google Cloud Professional Cloud Security Engineer

Amazon Web Services(AWS):

With AWS they have a few tiers depending on your experience so I’ve always tried to opt for the Professional level, as it’s much deeper and for a security professional who doesn’t like getting unpleasantly surprised it’s excellent as it provides more depth in many critical components.

AWS Certified Cloud Practitioner
AWS Certified Solutions Architect
AWS Certified DevOps Engineer
AWS Certified Security Specialty

Microsoft’s Azure:

I haven’t participated in any big projects related to Azure, so just to have some overview of the platform I took the following courses:

Microsoft Azure Security Technologies
Microsoft Azure Architect

And when it comes to really generic training or certifications, I’ve enrolled for a course preparing for ISC2’s Certified Cloud Security Professional training which was nice but I probably should’ve had done it years ago to really benefit from it.

Note that I haven’t gotten myself to go after the actual corresponding certification after completing the courses/training, because to me the paper isn’t worth spending $500 per each and stressing about my scoring. It’s just my personal decision and I’ve never been interested in spending money on things that don’t directly improve my working knowledge, but it doesn’t mean you shouldn’t do it. If you want to spend the money or you have the company covering your training + certification costs then, by all means, go for it, because for some employers it matters and some folks enjoy passing the exam.
To me, during my whole formal and informal education I was never excited about passing exams. I guess it’s just my nature, because I’m always looking at the next thing I’m going to do after finishing something and I’m more excited about getting myself into the next course and using my money to grow and through my professional growth be able to bring more value to the company I work for.
The cost vs benefit ratio never made sense to me, but I wanted to write this paragraph to let you know that it’s not necessary but if you want to – go for it. Still, this is just my opinion of a guy who’s pretty conservative when it comes to spending money.

At the end of the day, a security architect is a role where you don’t just build secure software or secure infrastructure. Your point of focus is on building a security company/securing your business, which is where big-picture perspective gets beneficial, so while I focused here on the cloud environments, I think you should really try to make yourself familiar with as many building blocks of your company as possible. Obviously, you need to assess what’s beneficial and what not and what type of sacrificed you’re willing to make, but I’ve never seen anyone’s career being hindered by knowing too much.
Even though I’ve started working in the role of a security architect over 4 years ago, I’ve all that time focused on becoming. Becoming better at being a security architect, because getting into that position is just a test of your basic abilities required to get an opportunity to start the journey of becoming a good Security Architect.

To sum it up, if someone is wondering what to do to become better I think the training/certs listed above are a fine way to go about it. I’m not saying it’s the best or the only way to do it, but if you have no idea where to go next – which was the case for me for a way too long time – then it’s better to pick either of those and do something. It’s always better to do some than do none.

All the best to Y’All,

[PL] Jak przygotować się do zdania certyfikatu OSCP

Całkiem często pojawia się w polskim community pytanie odnośnie tego jak poradzić sobie z certyfikacją Offensive Security Certified Professional, więc uznałem, że troszkę wypada dorzucić swoje trzy grosze biorąc pod uwagę to, że w ciągu ostatnich 3 lat rekrutowałem kilkadziesiąt osób do różnych działów cyberbezpieczeństwa i sporo z tych osób próbowało swoich sił właśnie z OSCP.

Obserwacje sceny globalnej jak i prywatne doświadczenia sprowadzają moją opinię na temat zdawalności OSCP to następujących sugestii:

Najlepiej do egzaminu przygotują Cię laby PWK, a powtórka egzaminu jest tania jak barszcz więc nie masz się czego obawiać.
Co do mocnych zasobów z tipami to polecam wpisy na blogach ludzi, którzy dokładnie opisuja swoją drogę przez mękę tzw ‘Try Harder’ 🙂
Googluj po słowach kluczowych takich jak “My OSCP Journey” “Journey to Try Harder”
Tutaj przykłady takich zasobów z mocnym zgrupowaniem personalnych historii:
Sam OffSec ma na swojej stronie linki do testimonials ludzi którzy konczyli certy. Nie pamiętam dokładnie linku, ale na pewno na githubie jest repo które linkuje setki writeup’ów ludzi którzy przechodzili przez certy oscp, więc polecam sprawdzić ten kierunek + na twitterze są hashtagi #oscp #tryharder z których mnóstwo personalnych historii wyciągniesz.

Historie pisane życiem są najlepsze i community ‘Try harder’ bardzo dużo energii zazwyczaj wkłada w swoje blogposty, więc powinno Ci się spodobac.

O failu z buffer overflow pierwszy raz słyszę – zarówno w PWK jak i na egzaminie OSCP zadania związane z low-lvl exploitation są mega łatwe(kilkanaście minut do rozwiązania) i nie znam nikogo komu by się nie powiodło 🙂Często to zadanko się robi na początku na dobry start, bo o ile ma trochę punktów to jest takim słodyczem na zachętę.

Natomiast bardzo często egzaminy ludziom padają ze względu na braki w wiedzy/doświadczeniu związanym z privilege escalation.

W każdym razie – nie macie się czym stresować, laby PWK wszystko Wam wytłumaczą a na egzaminie nie ma niczego czego nie byłoby w labach.

Co do maszyn vulnhub/hackthebox/attackdefense jak najbardziej na +++++

A co z innymi certami takimi jak Security+? Na to pytanie odpowiem w dłuższy materiale już niedługo, natomiast na tę chwilę wrzucę:

Jeśli dobrze pamiętam to cert Security+ to ~1.2k PLN, więc jeśli zależy Ci na dobrym ROI to lepiej zainwestować te pieniądze w sensowniejsze zasoby.
A jeśli chcesz się nauczyć materiału, który obejmuje Security+ to generalnie jak najbardziej polecam bo dużo z tego można wyciągnąć. W tym kierunku polecam darmową serię mega dobrych nagrań Professora Messera:

Ten kawałek wiedzy jest darmowy jeśli klikniesz w zasób który podlinkowałem. Kosztowny jest cert, który jak ze wszystkim w życiu – przyda się, ale i bez niego da się karierę poprowadzić.
A tak mówiąc już brutalnie szczerze – szukaj raczej miejsca pracy w którym zweryfikują Twoją wiedzę i umiejętności(gdy np. wykażesz się dobrą znajomością materiału z kursu p.Messera), bo tak w życiu się często składa że koniec końców firmy które postrzegają pracownika przez pryzmat papierów czy innych bzdur jak kolor włosów, to często firmy w których i tak szkoda marnować życia na pracę:)

Jak przetestować bezpieczeństwo własnej aplikacji i serwera

Często w sieci trafiamy na pytanie “w jaki sposób przetestować bezpieczeństwo mojej aplikacji/mojego serwera”,  na co chętnie odpowiadamy zarywając kolejną noc i pisząc kolejny esej.

Z esejami w branży security jest tak, że o ile fantastycznie pomagają nam podbudować ego, to niewiele rzeczywiście wartości wnoszą do życia osoby, której wydawało nam się, że chcemy pomóc.  Cenię sobie każdego kto ma dobre intencje i poświęca swój czas by pomóc innym, ale po wielu latach w infosec, trzeba przeprowadzić reality check i spojrzeć prawdzie w oczy.

I ta prawda trochę w oczy zapiecze, bo okazuje się, że często nasze działania mijają się z celem. Zamiast dostarczyć komuś narzędzi za pomocą których osiągnie swój cel, to zarzucamy ludzi mnóstwem informacji, które same w sobie są wartościowe, lecz większość programistów/sysadminów po prostu nie ma czasu na analizowanie tak głębokich wypowiedzi.

W większości sytuacji, dobra rada to taka, która pozwoli komuś skutecznie rozwiązać problem, a wszystko dodatkowe to tylko szum.

Jeśli jesteś osobą zainteresowaną rozwojem w branży bezpieczeństwa IT, to śmiało rzuć okiem na moje długie artykuły/podcasty/szkolenia online w których obszernie wyjaśniam wiele tematów.  Natomiast jeśli nie chcesz zmieniać całej swojej kariery w kierunku infosec i chcesz po prostu sprawdzić podstawowe zabezpieczenia w swojej aplikacji, to na pytanie:

Jakie narzędzia automatyczne pomogą mi przetestować moją prostą aplikację na localhost+XAMPP?


 Jeśli to localhost i chcesz się pobawić, to pobierz sobie Armitage i puść Hail Mary z agresywnymi exploitami z metasploita żeby Ci napsuł tyle ile się da.
Do tego z narzędzi, które są point & shoot to 99% tego czego potrzebujesz załatwi Ci:
OpenVas (opensource alternatywa Nessusa, tj. bezpieczeństwo sieci/hosta + znane podatności oprogramowania zainstalowanego na hostach – wliczając webappki)
OWASP ZAP – do dynamicznego testowania bezpieczeństwa aplikacji webowej

Zarówno w Armitage, OpenVas i ZAPie daj im dane logowania do hosta z najwyższymi uprawnieniami, tak żeby mogły przeorać wszystko co możliwe.

Z w/w narzędziami przeprowadzisz atak na >98% świata, XAMPPA wliczając 🙂 Pobierz narzędzia, pobaw się, daj znać gdy pojawią się pytania.

Enjoy 🙂

A gdy pojawią się jakieś pytania, to najprawdopodobniej ktoś już kiedyś wpadł na podobne pytanie i odpowiedzi na nie znajdziesz już dostępne w sieci, więc spróbuj najpierw pogooglować i pobawić się samemu. O ile generalnie rzeczywiście zaoszczędzisz trochę czasu w danej chwili jeśli spytasz kogoś o radę na tematy które były już poruszane setki tysięcy razy, o tyle długoterminowo lepiej będzie dla Ciebie jeśli przyłożysz się do własnego researchu i praktycznego dotknięcia tych wszystkich narzędzi/systemów.

Krąży po świecie taki ładny cytat, który przez swoją ponadczasową mądrość jest przypisywany wielu wielkim – od Konfucjusza, przez Lincolna po Franklina. Więc przytoczę go też i w tym blogpoście, bo niewiele w życiu prawd jest tak aktualnych jak właśnie ta:


“Tell me and I forget,

teach me and I may remember,

involve me and I learn.”

Do roboty! 🙂

13 basic steps to start a practical implementation of DevSecOps at your organisation

Hello Friends,

I want to share with you a blogpost I created as an attempt to bring some more clarity to the concepts that are [finally] getting more attention of the public.
I’m a solid believer that the potential of the tribe can be tapped into it’s full extent only if all the members of the community are able to communicate freely with each other and exchange the ideas. Same way we can’t solve a problem if we don’t know if there is a problem or what is the problem, I believe for us to innovate and bring our ideas to fruition we need to our language and simplify the overcomplicated terminology. But that’s just me being me with my lengthy intros to what’s about to come next, so let’s cut it short this time and get to the specifics.

Secure SDLC requires multiple steps to be completed in order to secure whole software delivery cycle, although each step alone significantly contributes to overall security posture of an organisation. Implementation of Secure SDLC in AgileDevelopment requires transformation of traditional collaboration workflows, where security teams worked as an independent consultancy offering their support on demand basis, whenever needed by software engineers. With Agile development where speed is the most important variable, there is a need for shifting security to the left of SDLC, minimizing exposure in later SDLC phases and decreasing the costs of remediation of security issues when they’re discovered. Besides the decreased total cost of software development, DevSecOps brings a concept of servant leadership to the security ecosystem, improving the overall culture of the organisation and reducing the friction between security operations and all other employees.

I like to explain the practical difference between Secure SDLC and DevSecOps in the following way:


SSDLC is meant to answer the technicalities of the vital questions in any transformation process, i.e. “what”, “when”, “where”, “how”, and “why” and in this particular context it’s pretty much meant to address what’s been known since 2002 as Microsoft’s SDL. You can read it as processes, procedures, tools etc. which you plug into your SDLC workflow to ensure that each phase of SDLC has a corresponding security instrument initiating some sort of activity meant to reduce the security exposure created by/in the final product.
DevSecOps is then a cultural movement meant to ensure everyone across the whole organisation understand the answer to “why” well enough to actually want to care about all those security things.
To follow SSDLC is to prepare an environment which just makes your products and organisation safer. To advocate DevSecOps is to encourage people to put in use all the great things you’ve prepared for them with SSDLC setup and to not despise the additional burden – rather to enjoy the vision of being able of supporting the common effort to ship safer products which support the bottom line of the company which in turn takes care of its employees.

To me, it’s all about using all the instruments available to create a win-win environment, and that requires a willingness to work on bringing everyone on the same page with the cultural transformation of your organisation.
If you as a security professional aren’t willing to believe that you can manage collaborating with other people at your organisation(be it engineering, sales, helpdesk, the board and all in between) you won’t be able to bring a meaningful change. We know how this story goes, because for the past few decades we’ve tried to convince other people to do something just for the sake of doing it and we see where it got us, so it’s about time to try another approach. And that DevSecOps is what I call an empathetic and result-oriented approach of tackling the security challenges of the modern software-related companies.

Although this explanation seemingly ignores a significant amount of details and may be looked upon by experts as over-simplistic, it just gets the job done. If you’d like to learn more about the effective means to use a language as a tool for getting your job done, you may want to take a read of the following article:
And here is a list of 13 specifics that I like to use as an initial outline of the attempt to analyze the scope of the transformation:

  1. Create a roadmap for an education of all technical stakeholders such as software engineers, QA testers, product owners and engineering managers on secure software engineering. Education process should include trainings/workshops meant to increase the technical skills related to secure programming as well as making employees aware of corporate securitypolicies, procedures, processes and best practices. The later provides employees an opportunity to obtain a wider perspective enabling them to come up with their own ideas on how to build a contextual defense mechanisms linked to the feature they’re developing at the moment.
    Security training should be conducted in a form of interactive workshops, to create a personal bonds between security staff and other employees and to increase the odds of personnel remembering the entertaining learning experience. Going forward, employees should have access to comprehensive knowledge-base e.g. in a form of automated learning platform that allows access on ad-hoc basis when they need to learn about safety of currently developed software module.
  2. Educating all business units on how security should be instilled into SDLC and day to day work of their teams. Approach top to bottom helps ensure that the management actually provide employees needed resources to do their work securely.
  3. Creating a culture of collaboration between security and all other departments in the spirit of DevSecOps, which emphasised empathetic and servant leadership. Security team should be deemed an indispensable member of each department, sharing their knowledge as well as acting as Subject Matter Expert in their domain of expertise – as opposed to an external silo which receives a cold requests to perform security testing of an already developed product.
  4. Deploying systems and code auditing tools to ensure higher coverage of security assurance. This includes involvement of automated scanning technologies across the whole technology stack used by an organisation. Implementation of those tools not only helps to identify security issues, but also by delegating remediation to a person that introduced a security flaw, enables practical education process where employees understand what they should do better in the future.
  5. Defining explicit minimum security requirements for each new application, where software engineers understand how things should be ran at the organisation in compliance with security-related departments. In Agile world, each back-and-forth with security team is a waste of time, which is why all documentation must be prepared upfront and delivered to relevant stakeholders.
  6. Creating quality bars that define on which risk levels it’s feasible to fail the build and not allow software to reach production, based on the assessment performed by automated systems for code scanning, dynamic application scanning, config auditing as well as manual testing.
  7. Incorporating one-time manual and automated threat modeling and design reviews. Reviewing software design at earliest and final phase of SDLC enables you to provide contextual guidelines for development teams, as well as to prepare security department for risks associated with development of very specific software so that all entities are prepared for reverification of mission critical components. Training product owners and systems architects how to create threat modelsallows to perform risk analysis at lower cost without direct involvement of a security team.
  8. Defining automated tools, benchmarks, security checks and baseline which explicitly enforces usage of specific security safeguards. Think of always enforced compilation flags on a build server, where security is bolt-in by default.
  9. Deprecating unsafe software and dead code. Automated analysing software for dead code as well as insecure and outdated dependencies significantly lowers the risk profile of an organisation and developer software. If automated systems are in place to achieve this, then software engineer can immediately react to an alert about insecure dependencyand upgrade the library in subject to secure minor version with security patches without significant impact on systems stability. Not upgrading libraries often leads to situation when there is too big difference between version used and expected, which may introduce too many changes to the system, which in turn increases the costs of software development by requiring additional testing performed by manual QA engineers .
  10. Performing Static Application Security Testing. SAST tools are should be plugged into Continuous Integration & Delivery pipelines to run automatically after each change to the system – such as each new commit to Version ControlSystem – and periodically, independent of release schedule.
    Software Engineers should be also allowed to swiftly run those tools independently on their machines at as low cost as possible.
  11. Performing Dynamic Application Security Testing. DAST tools should be plugged into Continuous Integration & Delivery pipelines to run automatically after each change to the system and periodically, despite release schedule. Software Engineers should be also allowed to swiftly run those tools independently on their machines at as low cost as possible.
  12. Performing Fuzz Testing, which is sending to an application unexpected types of random data that helps undiscover security issues that may be affecting whole CIA-triad(Confidentiality, Integrity, Availability). Fuzz testing is important to mention here, because while most of the automated systems are meant to ensure company’s compliance with certain standards and security baselines, fuzz testing is meant to expose unexpected security flaws that may have went under the radar of automated tools and software engineers.
  13. Performing manual review of tools and documentation output pre-release, to ensure high quality review with involvement of a human element.

In any case, I hope this article comes useful to you – whether you’re trying to gain a bit of an infield perspective into the world of Secure SDLC & DevSecOps, or if you’re a security professional looking for some basic steps to kick-off the process of trying it out at your organisation.

Have a great weekend Y’all and I’m looking forward to your feedback!


PS. More content on this subjects coming out soon 🙂

Własny LAB do nauki pentestów – jak zacząć

Niedawno na Facebookowej grupie “Testowanie Oprogramowania” pojawiło się ciekawe pytanie:

Próbuję się przekwalifikować z testera manualnego na pen testera. Zmieniłam teraz pracę i jako pierwsze zadanie jako nowy penetration tester zostało mi polecone zbudowanie laba. Narazie nie wiem jak zabardzo to ugryźć.

Ogólnie dopiero formujemy security team więc wszystko jest jeszcze bardzo płynne. Docelowo lab ma służyc do werifikowania security vulnerabilities w naszym produkcie. Plus narazie mamy firmę która raz w roku robi nam pen testy ale chcemy to zacząć robić sami, więc to ma też być pewnego rodzaju playground

Na które jako tako udało mi się odpowiedzieć, więc wrzucam też na bloga dla potomnych:


1) Jeśli pytasz o LAB w kontekście środowiska gdzie możesz się uczyć testować bezpieczeństwo, to ten artykuł opisuje praktycznie wszystko co jest Ci potrzebne żeby wystartować i mieć czym się zająć najbliższy rok (jest stack webowy do testowania webówki, i jest też metasploitable do wdrożenia w pentesty infrastruktury).…/
Masz tam też wypisane informacje odnośnie narzędzi, które powinnaś wykorzystywać jako swoje środowisko pracy do przeprowadzania testów, tj. wszystko począwszy od local proxy, przez automatyczne skany podatności, po nasłuchiwanie ruchu sieciowego.
Kilka innych zasobów, które pomogą Ci zbudować LAB w obrębie kontekstu, którym jest piaskownica w której możesz się bawić i rozwijać swoje umiejętności.…/…/basic-penetration-testing-lab-1…
Przyda Ci się też książka Georgii Weidman, która mimo że jest już trochę przedawniona, to w bardzo ustrukturyzowany sposób przeprowadzi Cię przez to jak profesjonaliści infosec tworzą środowiska do samorozwoju:

2) Jeśli pytasz o konkretne narzędzia i to jak zrobić LAB do samorozwoju na większą skalę, to po prostu przyłóż się do OSCP. Napisałaś, że robisz OSCP, a Laby PWK to jedno z najlepszych środowisk na świecie z których wyciągniesz zarówno konkretne umiejętności techniczne jak i zobaczysz w jaki sposób zbudowane są LABy składające się z kilkudziesięciu hostów.
Po OSCP jeśli interesują Cię desktop appy, to nie popełnisz błędu idąc w kierunkcu OSCE.
Niedawno Offensive Security wypuściło jako kurs online szkolenie i certyfikację dla pentestów webowych, tj. Advanced Web Attacks and Exploitation (AWAE) + OSWE

3) Czytając jednak Twoje komentarze, odnoszę wrażenie że firma chce żebyś zbudowała środowisko typu piaskownica służące do testowania bezpieczeństwa produktów które wytwarzacie. Tutaj rocket science nie będzie, bo potrzebne jest zwyczajne środowisko z jakiego korzysta do testów Dev/QA w Twojej firmie. Natomiast jeśli chodzi o drugą część tego środowiska, tj. podpięcie narzędzi do ciągłego zapewniania wysokiego standardu bezpieczeństwa produkowanego oprogramowania to odsyłam Cię do zasobów opisujących praktyczną implementację Secure SDLC:…/securityengin…/sdl/practices

Przykładowe narzędzia masz opisane tutaj:

A do aplikacji desktopowych powinnaś zapoznać się z fuzzerami jak np. American fuzzy lop oraz narzędziami do statycznej analizy kodu, tzw SAST, np. OpenStack Bandit.
Listę tego typu narzędzi znajdziesz tutaj:

Tak więc powodzenia i trzymam kciuki za Twój dalszy rozwój kariery – jest co robić! 🙂

Which birds get the worm? On sleep schedule and toxic dogmas.

I know plenty of the biohacker community our there is struggling with their waking hours. They believe in the grind, they believe in the hustle and they want to achieve the success at all cost. I understand that very well because that used to be my native self as well. It’s a long story how it all came to be that I’m in a different place right now, but the message I want to share today is the following.

You really need to find what works best for your psyche and circadian rhythm. You can fight your body if it’s going to benefit your mind, but don’t get yourself on daily mental warfare with things that can be made easy. The world doesn’t care if you’re a bird, an owl or a wolf. Jocko is rolling out of bed at 0445, I’m rolling out of bed at 0430, GaryVee doesn’t sleep at all, and some of the people who’ve achieved a massive success sleep till 10AM; but it doesn’t matter.

We all do it because we worked out what works best for us. We’ve used the pain to find what makes us love and respect ourselves even more. We haven’t experienced pain because we love pain, but we’ve agreed to experience the struggle for a while to get out stronger and smarter.
Many people forget about that and believe that the game is all about the pain and struggle. Well, you’ve bought in the same messy paradigm I used to live in. If you hate your life because you’ve made yourself believe in a dogma that the early bird eats the worm then you’ve played yourself, a big time, buddy. We’re in abundance of worms, everyone can get some if they go after it – regardless of the time they wake up or go to sleep.

It’s ridiculous how some harshness in our lives is just a matter of the perspective. I choose to believe it’s easy and many things roll on their own. If it turns out to be hard then life will self-correct itself and teach me a lesson, but why would I stop myself if odds are in my favor?  Now at the point where I couldn’t care less about most of the things I cared way too much in the past, I’m surprisingly having more energy to put puzzles in the right places and continue going to my personal toooooop!

Getting back to the biohacking things – if you’re playing with optimizing your body and mind, but you’re not on top of the research from @bulletproof / @dave.asprey then you’re just playing yourself. Go check out his company’s website or even better so, grab a copy of his latest book and put some order to the chaos in your life.
And for real, fight that scarcity mentality, because it’s killing you. Look beyond your limiting beliefs and stigmas. Just go, and obviously, add some flavor to your life by flipping a regular coffee for the Bulletproof coffee! 🙂