[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:

https://www.professormesser.com/security-plus/sy0-501/sy0-501-training-course/

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?

odpowiem:

 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: https://www.peerlyst.com/posts/learn-how-to-speak-business-language-or-effective-security-management-part-3-dawid-balut
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!

Dawid

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).
https://resources.infosecinstitute.com/how-to-make-your…/
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.
https://resources.infosecinstitute.com/building-your-own…/
https://medium.com/…/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:
https://nostarch.com/pentesting

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:
https://www.microsoft.com/…/securityengin…/sdl/practices

Przykładowe narzędzia masz opisane tutaj:
https://www.devsecops.org/blog/2016/5/20/-security

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:
https://github.com/mre/awesome-static-analysis

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! 🙂

Mój podcast dostępny na Spotify, Anchor.fm, Stitcher i wielu innych!

Wielu z Was rekomendowało abym wrzucał swój audio content na wygodniejszą niż YouTube platformę. Od teraz możecie spodziewać się moich treści na platformach takich jak:

Anchor.fm: https://anchor.fm/thedawidbalut

Spotify: https://open.spotify.com/show/1EddZF7ugZ2HT2sLQcsyxT

Stitcher: https://www.stitcher.com/podcast/anchor-podcasts/dawid-balut-purposeful-ranting-2

Breaker: https://www.breaker.audio/dawid-balut-purposeful-ranting

Castbox.fm: https://castbox.fm/channel/id1508995?country=pl

Google Podcasts: https://www.google.com/podcasts?feed=aHR0cHM6Ly9hbmNob3IuZm0vcy80YWIyOGYwL3BvZGNhc3QvcnNz

RadioPublic: https://radiopublic.com/dawid-balut-purposeful-podcast-GMayPZ

Pocket Casts: https://play.pocketcasts.com/web/podcasts/share?id=1004f5b0-4b0d-0136-fa7c-0fe84b59566d

i oczywiście YouTube: http://youtube.com/thedawidbalut

Dzięki i do usłyszenia! 🙂

My book “Social Skills For Information Security Professionals: A Handbook For Those Who Strive To Lead And Manage Effectively” is live

Here it comes!

11 years of learning, 2 years of writing, 84 pages for you to read. 🙂

You can download a pdf here: Social Skills For Information Security Professionals: A Handbook For Those Who Strive To Lead And Manage Effectively by Dawid Bałut

And a few words on how it all came to be that Peerlyst is a publisher and a patron for my book…

I must admit that this book most likely wouldn’t have happened if it wasn’t for a great infosec community I’ve found in 2016. Over 2 years ago I’ve found a website called Peerlyst which turned out to be the startup with a mission to create the best collaboration and knowledge transfer platform for security professionals.

I’ve found it because one of the users ( imad bsd‍ ) posted there a link to an article on my blog, and I’ve noticed many visits from one source. Curious to see what it was all about I visited the peerlyst.com and found overwhelmingly positive feedback about my content. Finally, I’ve found a place that felt like sort of a home I never really had. A place where even if people don’t agree with you, they don’t make you feel like a piece of crap but provide you friend insights which you can then use to learn and grow.
Fast forward a couple months later, Peerlyst created an initiative to write a crowdsourced book on “Essentials of Cybersecurity: How to get the basics right”, where I volunteered to write a chapter about something I’m deeply passionate about as it connects a few deep interests of mine, i.e. business, infosec, psychology, and sociology. My chapter called “Building a corporate security culture” has been such an exciting subject to me, that I’ve written over 10 pages despite being asked to provide only 2-3 pages. I wasn’t really surprised when I’ve heard that most of my content didn’t fit in, because there had to be a place for chapters of other great individuals. As I couldn’t let go to waste something I strongly believed in, I decided to publish at Peerlyst the subchapters that didn’t get it into the ebook. Turned out that once again that the community appreciated my contribution and my posts sparked a huge discussion on the soft side of our jobs and allowed me to learn a ton from experience of other professionals coming from very diverse backgrounds. After so many great discussions, after seeing people opening up about their personal life, about the relationships issues they’re facing because of the stress at work, about the health issues generated by their anxiety, I felt obliged to create a resource which could help others at least a little bit. I know how it feels when life just ain’t right and you start to lose hope. I got to know people who were in the same spot as me and it would be cruel of me to not share the tips that have helped me regain my sanity and achieve some level of professional and personal success, i.e. happiness.
Happiness is a never-ending chase, but it’s still something if you at least hate your life a little less.
That’s the reason why I’ve spent the next 2 years writing this piece of art and assembling only the advice I truly believe to be universal, practical and helpful for the community.

Deep inside I believe that running into Peerlyst was one of the best things that happened to me. I haven’t made any money out of it, I haven’t sold anyone anything, and I never intend to monetize on them, because way too much I appreciate what they have already given me in return. I earnt an unbelievable feeling of connection with the community of people who I’ve been searching for my entire life.

Being a part of something bigger, learning from the greatest and having an opportunity to exchange feedback is something that can’t be compensated with any money.

I’m simply grateful because the mission to help others live better lives is something extraordinary that Peerlyst is allowing me to do.

Table of contents:

  1. On my motives for this book 4
    1. How and why – I believe – can my story make your life easier 4
    2. How and why – I believe – my story can make you avoid personal and professional suffering 6
    3. How to squeeze maximum value out of invested time in reading this book 8
  2. Align strategy with business stakeholders first 10
    1. Who’s actually responsible for investments in security? 10
    2. It all goes top to bottom, the culture and tone set by execs is a real thing 11
    3. Set common goals with management and executives 12
    4. Settle down on authority at the earliest 13
  3. Build credibility and learn the language of business 14
    1. Stay away from spreading confusion and FUD 14
    2. “Make it till you make it” is a much better strategy than “Fake it till you make it” 16
  4. Everyone is a target these days, but are they truly aware of it? 17
  5. Agile implementation of security into a corporate culture 18
    1. Start small 18
    2. Start early 20
  6. Outline SDLC/NDLC improvements 21
    1. Security should be perceived as any other cost of running a business 21
    2. Hold them accountable to high standards, but keep your expectations low 22
    3. Build a Secure SDLC 23
  7. Show up, adapt and deliver results 25
  8. Make security simple 26
    1. Simplify it for them 26
    2. Everything is just a tool and the mission is the only thing that matters on the macro level 27
    3. Encourage and teach instead of demanding and judging 27
    4. Extensively explain security requirements and identified issues 28
    5. No matter what your specialization is, we all share the same goal – improving the defense 29
  9. Do the work behind the scenes and don’t be a workflow bottleneck 30
    1. InfoSec as an enabler 30
    2. Listen and execute behind the scenes 31
  10. Embrace DevSecOps 32
    1. Become a member of each department 33
    2. Delegate instead of trying to fix everything yourself 34
  11. Internal security training and awareness awards 35
    1. Conduct recurring security training 35
    2. Popularize internal Bug Bounties and awareness recognitions 36
  12. Security Is An Art Of Tradeoffs So Learn How To Manage The Risks 37
    1. Be practical 37
    2. Allow cutting corners when necessary 38
  13. Learn how to run productive security meetings 39
    1. Create a friendly atmosphere during your meetings and spend most time listening 39
  14. Leave Your Ego At The Door And Study Empathetic Leadership 41
    1. Make it all about them by making it personal 41
    2. Never play the shame or blame game 42
    3. Don’t forget about non-techies 43
  15. Leadership values and Emotional Intelligence 44
    1. Be a leader you wished you had and remember that we’re all just humans. 47
    2. The long-term efficiency requires you to do things the right way 47
    3. It’s easy to destroy relationships and hard to rebuild them 48
    4. No place for ego in the effective management and when less is more 50
    5. Listening is a skill which requires constant training 53
    6. Memory exists so we don’t repeat the same mistakes again, not so we romanticize the painful experiences and live in the past 55
    7. Appreciate feedback every single time you get some 56
    8. Make them safe and make them feel the comfort of that safety 57
    9. On toxic and productive criticism 58
    10. Watch your language and respect your peers 59
    11. Blaming, shaming, pointing fingers doesn’t help anybody. Never, nowhere. 61
  16. Growing thick skin in InfoSec 62
    1. Dealing with negativity and destruction is a part of nature 62
    2. On the truly negative 63
    3. Sometimes the best way to win is to quit 65
    4. Don’t shy away from showing off your success 66
  17. After all, it’s all about protecting the money-making machine 68
    1. Make each action purposeful and data-driven 68
    2. Adapt, adjust and execute 69
    3. Securing the money-making machine is the prime objective 70
    4. Business context matters. A lot. 72
  18. Effectiveness, High Productivity and Fulfillment in the InfoSec — The Game That Never Ends 75
    1. Don’t make it hard for people to get involved 75
    2. Stay humble, no matter what 75
    3. Value their time over yours 76
    4. Create a culture of appreciation 76
    5. Don’t take good results for granted 77
    6. Avoid myopic decisions to save your reputation 78
    7. Don’t let the stress and short-sightedness slow your company down 79
    8. Become a lifelong learner 80
    9. Go the extra mile 81
    10. The game that never ends 81
    11. Be selfish 82
    12. Now it’s all up to you… 82
  19. Dawid Bałut bio

A jak wygląda Twoja definicja sukcesu?

Bo żeby osiągnąć sukces, to najpierw musisz dobrze zrozumieć czym sukces jest dla Ciebie. 
Dlatego właśnie dla większości ludzi każdy rok jest taki sam i nie ma znaczenia, czy żyją w 2014 czy 2019, bo ich poziom życia, szczęścia czy spełnienia jest ciągle taki sam.
 
Jeśli to Cię dotyczy i czujesz, że lata mijają a Ty mimo ciągłej gonitwy i ciężkiej pracy nadal jesteś w tym samym miejscu to warto poczynić krok wstecz i porozmawiać z najważniejszą osobą w Twoim życiu – samym sobą.
Tego dokąd iść i co robić nie powie Ci żona, mąż, brat, siostra, nauczyciel a już na pewno dobrej drogi nie wskażą Ci social media i projekcje idealnego życia ludzi których śledzisz.
Mój sukces to mój sukces i w żaden sposób nie ma wpływu na Twoją definicję sukcesu. To jedna z najważniejszych definicji, którą każdy z nas musi uformować w domowym zaciszu.
Czasem trzeba spojrzeć w lustro i porozmawiać ze sobą by zrozumieć jaka jest Twoja osobista definicja sukcesu. Nie chodzi tutaj o teksty typu “zadaj sobie pytanie co jest dla Ciebie ważne i zacznij to robić”. Jedno pytanie nie wystarczy. Nie wystarczy też jeden dzień ani jedna noc , bo potrzebujesz dialogu a nie monologu, który to zazwyczaj wybieramy w zajętym życiu. Podczas monologu powtarzasz to co już wiesz, podczas gdy klucz kryje się w wyjściu w nieznane i kwestionowaniu obecnego stanu wiedzy.
 
Nic co wartościowe nie przychodzi w życiu łatwo. I to jest w porządku, bo inaczej życie byłoby zbyt nudne.
Do zobaczenia w 2019!

Social Skills For Information Security Professionals: On enabling others to perform at their best

Do the work behind the scenes and don’t be a workflow bottleneck

InfoSec as an enabler

If I were to choose only one thing to share with you, it would be that there is no place for a naysayer in a security department.

It’s unbelievable how many of us kept doing the wrong things for so long. It’s tough, because the impact we’ve had on IT societies is something that’s chasing us till this day. I’ve had to spend a lot of energy on working out healthy relationships with my peers by convincing them that not all security people are rude and negative. I don’t want to point fingers at anybody, because I’ve made those mistakes as well, however, we – as an industry – must acknowledge an elephant in the room and recognize how many cultural mistakes we’ve made in our careers. We must confront that our strategy of whining about insecurities of everything and desperate attempts to slow down innovation turned out impractical. We’ve tried hard to keep the comfortable status quo instead of learning the new technology and figuring out how to allow others to do their work more efficiently. We had good intentions, however, people couldn’t follow our incompetent lead and always found a way to bypass our restrictions.

I know it’s getting better and there are fewer infosec specialists who default to denial and rejection. Yet, I feel like it’s worth emphasizing that our ghosts of the past  made it tough for social-savvy security pros to create healthy relationships with engineers and other employees.

Saying no is easy, being creative and looking for innovative solutions is challenging and for us, hackers, we should strive to solve challenging problems as that’s part of our DNA. If you’re not creative enough, people will find creative ways to bypass your negligence and it’s all for nothing.

Your mission is to enable your coworker’s workflows and demonstrate that you actually have an honest intent and willingness to help them address challenges of their day to day struggle. Don’t romanticize the path you had to follow in order to be where you are today. Just because they haven’t been studying security for the last 10 years like you had and they aren’t aware of the risks involved with the technology they want to use, doesn’t entitle you to have an attitude and razz them for it. You’re there to help them, that’s why you are a security specialist, and you’re ought to use your skillset to support them, no matter what.

If you want to be a rock star, then earn that status, because the status is something that’s provided to us by a society, not something we tell ourselves. We can say as many blank statements as we want, but if our actions don’t back it up, we’re just being delusional. We’re hired to build robust products other people can use, and must use our greatness to solve the challenges. Even though it’s uncomfortable and it may be something you don’t want to do, it’s still the right thing to do.
So make sure you revisit your attitude, because even though your competence may be fantastic, your attitude must be in check as well to enable yours and your team’s productivity.

Listen and execute behind the scenes

Those who aspire to be great leaders must master one skill before others, because this skill alone can take them far and enable their growth in other areas. It’s listening and execution. Execution, especially when no-one is watching and expecting it.

Delivering the work no one asked you for, just to improve the life of your co-workers, is something that people know how to appreciate. So whenever you feel like doing something for the community, just do it, and the satisfaction will come to you sooner or later. Going the extra mile, is something that can help you build the image of yourself as an outgoing leader and problem solver. Our world needs people who identify problems and try to solve them on their own, without waiting for someone else to pick up the fight. People always seek someone to lead them. Someone who’ll inspire them and someone to whom they’ll be able to secretly look up to. Be that person, or at least give it a shot because there nothing you can potentially lose by doing the good work.

If you provide upfront a lot of value, people will feel emotionally obligated to give something back, because we can’t stand the feeling that someone gave us so much, and we haven’t even attempted to return some of it. It doesn’t need to be tangibles, the ROI can be their eagerness to work on security improvements for you. We’re all in human business, and technology comes second, so if you have good relationships with people, they’ll do something for you, even if it’s something they won’t be acknowledged for by the business. It’s in their human nature, and that’s all it takes.
Obviously, like for everything I’ve shared with you so far, there will be exceptions and you’ll face totally ungrateful people, but just because of those few individuals, you shouldn’t abandon the whole society of great people who’d love to work with you side by side.

Sometimes we just need to step out and take things in your own hands. Even if you think like there is no tangible incentive to do so, the feeling of doing something for better future of your coworkers is wonderful and justifies the sweat equity.

You must ensure that you’re doing whatever possible to show people your determination, competence, and passion, but be wary of taking too many little things — like code fixes — on your shoulders, because it may lead to cognitive and time overload. You can’t take so much on yourself that it’ll become impossible to do the actually important tasks that only you can do because of your skillset.

If it happens that you need to fix some code or tweak configs, then that’s perfectly fine as long as it’s an exception, not a rule. The key is the balance.

 

Embrace DevSecOps

The concept of purple teaming is something I fell in love with, many years ago when I was experimenting with a variety of ways to make myself more productive. Everything has changed  for better when I started embracing a culture of collaboration, where attackers and defenders work together to find the best approach of securing the products.

Although it’s great to focus on your narrow specialization and be an expert, it’s not the actual reason we’re getting paid. We’re getting paid to improve the safety of our organization, not just do the work for sake of doing the work. To be truly productive, I really recommend to at least try collaborating with all stakeholders across the organization.
Being a pwn-all-the-things rockstar will take you only this far. It’s overrated and while fun in short-term, gives terrible results long-term. I must remark tho, that there are great people out there, who provide immense value to the industry by doing only the thing they love but those are exceptions. It’s much easier to achieve success and long-term satisfaction if you learn how to work with others.

 

Become a member of each department

Having an independent security department is expensive and hard to scale. What worked for me, was working side by side with people who ship the products. This is a good thing to focus on, especially in small organizations where security culture isn’t yet established and people don’t realize they should inform you about some matters. While it is obvious to you and you expect them to use you as a consultant, people just often don’t have it on their mind if they weren’t ever required to do it before.

As a third party consultancy entity, you’ll be often late to the party, because people either forget, don’t have enough time for proper communication or are afraid that you’ll introduce additional burden to their existing workflow.

Becoming a team member will make everyone more socially comfortable with your presence and role, which enables you to cover more things with your security expertise. Some of us, painfully learned that approach “we VS developers” doesn’t really work if the goal is to create a healthy and friendly environment. If you introduce that competitiveness, it often creates a toxic atmosphere where people do their best to hide stuff from you instead of collaborating on convenient solutions

Join one team for a few weeks and then jump into another to create a well-intentioned relationship with your peers. Don’t just sit in your cubicle waiting for someone to call you for help, because that’s not going to happen.

 

Delegate instead of trying to fix everything yourself

To maximize your impact, you should learn how to delegate some of your workloads, because you don’t want to become a bottleneck for security improvements which is completely contrary to your goal. Except for time management and the fact you can’t always be a one-man army, there is an important educational purpose of tasks delegation.

By relaying work to a person who wrote or deployed the code/service, you help them understand mistakes they’ve made so they know how to do it better in the future. If you fix everything yourself behind the scenes, people will keep making the same mistakes over and over again. They may not be even aware that they did something wrong as no one ever raised any concerns in regards to their code quality.

Apply the same approach in all aspects of the business and educate people on how to improve the security of their day to day execution. You can, for example, teach internal QA teams on how to do basic security testing, thanks to which you’ll have additional eyes looking at the products from a different perspective.

Use your exceptional skill set to focus on things that matter and leave rest of stuff to others who’re more capable or who’re actually supposed to do given type of work.

If you’re great web pentester and good software engineer you surely can fix the bug you’ve found, but is it the smartest thing to do? If you’re the only security expert while there are 50 software engineers in the company you’re better off delegating the fix to others, so you can focus on execution within your domain of expertise.

 

Internal security training and awareness awards

Conduct recurring security training

Videos and online presentations are good, but nothing can really replace quality in-person meetups. Show as many demos as possible and don’t stick to overwhelming PowerPoint presentations which put people to sleep.

It’s fine to share raw technical details as a recap material, but while starting out you must make people excited about the subject, otherwise, it’ll be just another corporate training which they’ve attended only because it’s obligatory.

Don’t shy away from showing off your skills to non-techy people. It makes sense to show some real-life exploitation to impress them to build a great human relation and gain their respect for your skills even if they haven’t understood all of the things you’ve just shown them.

I personally like to show real-life testing, including very first steps from setting up Burp through vulnerability assessment, exploitation to data extraction. When you go step by step and show how you find a specific type of vulnerability — how you exploit it and how it can be fixed/prevented — people get the big picture perspective which is understanding the business risks. When they actually realize how code quality affects business longevity, they’ll pay much more attention to it.

There is plenty of Open Source resources that come handy in such exercises so squeeze the max out of them to create enjoyable and valuable security training.

Guiding them through detailed flow is practical, because while you’re doing the hacking part, the participants have a chance to directly and comfortably ask you many (un)related questions. Interactive meetings are the greatest, as they’re much better memorized than a blunt slide deck and they give you an opportunity to show the human part of yourself. Standing in front of people, gives you an invaluable opportunity to cultivate the relationships I’ve mentioned earlier.

The same concepts apply to physical and personal security and the key message is that training should be engaging, exciting and relevant. They should also be periodic so people are constantly reminded about the importance of security.

 

Popularize internal Bug Bounties and awareness recognitions

Bug Bounty programs are great and I’ve been a solid advocate of it for the past decade, but before you jump into spending crazy amounts of money on external BB, you should give it a try internally.

It’s smart to start with internal initiatives first and give your peers an opportunity to learn new skills and get some fancy rewards for their efforts. Consider hackathon-alike efforts where engineers can work on complex security issues they consider interesting, or just do some internal bug hunting with you.

While the BB is mostly a vehicle to create a security culture, there is actually a real chance of finding a few security issues because each person has a different perspective and a developer may find a bug in a place you’ve never thought of.

Make it fun and offer rewards like a few additional PTO days or gift cards for individuals who’ve found security issues in the specified timeframe or if they came up with great security tool during the hackathon. Except for the fact that everyone likes awards and rewards, people get excited when they’ve been publicly recognized as security aware. At most organizations, people remind being razzed for security, rather than being appreciated, so you’ve got a chance to use it in your favor. Don’t forget to properly acknowledge the effort of all those who’ve also tried but weren’t as successful, because you want everyone to feel engaged and appreciated.  You can use the Bug Bounty concept for non-technical people as well to show your appreciation e.g. if they report you a physical security incident. The key is that you need to cover the whole organization with the awareness because the security is as strong as its weakest link.

Initiatives like this help shaping a culture where being security aware is appreciated and rewarded and after a while, it can become employees’ habit to take care of company safety. Besides all security benefits, it’s simply a great team building exercise that organizations so you should employ on regular basis.

“Tell me and I forget; teach me and I may remember; involve me and I will learn.”