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

Jako dumny gość drugiego odcinka podcastu QAudycja!

Tym razem miałem zaszczyt pojawić się jakos gość w drugim odcinku nowego podcastu Konrada z QAudycja​.

Opowiadałem o karierze w bezpieczeństwie, o cyberbezpieczeństwie Polski oraz mojej nowej przygodzie zawodowej.
Klasycznie pojawiła się też garść informacji o codziennym radzeniu sobie z życiem, w szczególności o intensywności, ludziach dobrych i negatywnych oraz o wpływie środowiska na to jak kształtuje się nasza ścieżka prywatna i zawodowa.

Serdecznie polecam, bo poziom pytań Konrada był fantastyczny a On dopiero się rozkręca!
Trzymam kciuki za sukces jego bloga oraz podcastu 💪.

TestDive 2018 – DevSecOps implementation i.e. a culture of care

This year, I was invited to speak at TestDive 2018, an event sponsored mainly by Nokia and organized by fabulous people working at Nokia Kraków. It’s a great honor when someone asks you to talk at the conference of such a scale, and I was the lucky one this time.

Based on the amount of great feedback that I’ve received after the talk, it sounds like I did quite okay 🙂 And that’s awesome, because the subjects I talk about are rarely sexy. It’s practitionership, it’s effectiveness, and more often than not it’s far from flashy and overhyped solutions.  Cyberresilience isn’t a state you achieve by plugging in that one overpriced box into your network, or by hiring that one security guru. It’s about constant education, collaboration, understanding and daily grind meant to move a needle just a little bit.

Rome wasn’t built in a day. But it also didn’t collapse over night. Everything takes time, and if you’re not actively focusing on building the right culture, you’re ultimately ruining it.  That’s what the game is all about, just the grind and doing what needs to be done.

Anyways, I want to definitely send some love to Robert Becker who invited me to be a speaker, and who guided me through the whole process. It’s been a busy few months for me, so having someone like Robert helping me out and pinging me whenever I’ve forgotten to provide about some info was invaluable. You could feel the same sense of ownership during the conference, where everything was prepared top to bottom. We had fabulous announcer; great assistants from Nokia(thanks Maciej!), great atmosphere and venue was spot-on.

 

I do believe this was the most friendly conference I’ve attended this year. I don’t know what it was, and how that happened, but literally the moment I went through the doors I’ve felt like that’s it. I’m really looking forward to TestDive 2019’s edition,  and for one more time I want to say that I’m extremely grateful for being able to go on stage and share my experience with people who care enough to invest their time into listening to me, while they could be consuming the knowledge of other great speakers.

Love you all, your feedback is my oxygen. Now go and make some ruckus! 🙂

 

Here’s the link to the presentation:

https://docs.google.com/presentation/d/1hFIAYKObmPmvEr0CIZYnAP6DqgOuuuZPba2S-gD8Jqs/edit?usp=sharing

 

And here are the links to three parts of my book. The rest will follow the editorial redaction process and will be uploaded to my blog when it’s ready.

Preface:

https://dawidbalut.com/2018/09/19/social-skills-for-information-security-professionals-the-preface-to-my-book/

#1

https://dawidbalut.com/2018/09/19/social-skills-for-information-security-professionals-on-credibility-awareness-and-business/

#2

https://dawidbalut.com/2018/10/03/social-skills-for-information-security-professionals-on-agile-secure-sdlc-and-unhealthy-habits/

 

and my YouTube channel as few of you have asked for it:

https://www.youtube.com/thedawidbalut

Social Skills For Information Security Professionals: On Agile, Secure SDLC and Unhealthy Habits

Agile implementation of security into a corporate culture

Start small

I recommend you to take baby steps with all of the security initiatives you want to start at your company. By balancing the workload and adaptability you can demonstrate coworkers and executives that security doesn’t need to be tangled and complicated. If you show people that it takes just 5 clicks to enable disk encryption to improve safety of their PCs, it’ll be easier to have discussions with them in the future. After you’ve accumulated a few such small-wins, their mindset will change and they believe there actually are hassle-free solutions to security, they’ll be more eager to implement more of it.
Focus on the small wins and do the things that have the biggest ROI(Return Of Investment) and lowest cost of implementation and then steadily increase the complexity of security requirements.
1% is always better than 0. Small win executed today is better than an ideal win executed never.

 

The common mistake I’ve seen is that we  try to start out too big. We want to enforce all the security rules as soon as possible and sometimes even worse – all at once.
This approach may sound reasonable from a security pro’s perspective, because time is all we’ve got and each minute with security exposure is a minute an attacker can get a foot in the door.
However, it’s a complete failure from a practical business POV and I haven’t ever seen it being successful in the long-term perspective when someone tried to execute too many and too complex things at once.

Human beings are wired in a way that makes them dislike leaving their comfort zones, because the primitive part of our brain was programmed to keep us alive by avoiding risks.  In order to fight that, you must give people a tangible incentive for them to take a leap, because they must justify in their own heads why this particular risk is worth taking. Bigger your demand is, bigger the incentive should be, because the potential gain must be big enough for people to fight back the alerts their primitive brain is giving them. Yes, although nowadays we’re rarely required to make decisions that can kill us, that thing still resists when challenged with something new, because it doesn’t understand that discomfort . All it knows is that it must protect us at all cost, and it’s up to us – or actually other parts of our brain – to take a brave decision regardless.
It’s a good idea to start smaller with things that don’t push the comfort zone that much to earn the trust of your people. Most people are open-minded, but not that open-mindedly stupid to be leave their safe spot on the day 1, when they don’t know how good of a leader you are. And that’s for a good reasons, it’s not them to be blamed. People just want to be safe and we should respect that.


An example may be a common situation when you want to start implementing Principle of Least Privilege within your organisation. You shouldn’t just cut off coworkers access to all of their productivity tools, they were used to utilize on daily basis for the past few years. Do it in many small stages, one tool after another in reasonable time spans, otherwise you may outrage people when they lose access to things they were used to use freely. Not only it may cause them a discomfort but it can negatively affect the business when people’s morale are low, and their productivity is lower because they don’t have the tools they need to get the work done.

Building security is tough, not because it’s that technically complicated, but because it takes a lot of time, perseverance, patience and leadership skills. If you’re joining an organization that’s been on the market for a couple of years and never had a security person/culture before, you must prepare yourself for slow rollout of all those great ideas that you have.
It’s because people, who were never trained to be security-savvy, will have hard time adopting new requirements , even if you have reasonable justification for it. People like what they know, what they tested and know to be working and what feels like right for them. Because of our recklessness and mistakes we’ve made in the past 4 decades, we have earned not friendly reputation around infosec. It makes a lot of engineers think that security will make their work suck, so they do everything in their powers to stay away from it.

The best way to build credibility and have immediate results without irritating people is to start with subtle changes like showing the value of strong passwords, password managers, 2 Factor Authentication, Antivirus and frequent software updates . It may sound like nothing, but all adopted across the whole fleet will result in good security baseline that already puts your company in a few TOP % of safest companies. Even though those are the basic things and infosec folks like to go for fancy and overhyped security measures, I can count on fingers of one hand companies that actually have implemented above mentioned basics and done patch management right. That’s just an example tho.

That’s it, starting small is important. You won’t get much love for 30 days password expiry, enforcing security product with terrible UX or for cutting off access to critical services, just because you haven’t done good enough research to learn what is it, that people need to get their work done.

Start early

I can think of at least two main reasons why it’s reasonable to start with security at the project’s earliest. One, is that if you create a security culture in your organisation from its early days, you won’t give people a chance to learn bad habits of ignoring security. Second, is that it’s more expensive to change architecture design and refactor a finished product. Changing habits which essentially is rewiring brains of your employees is a very expensive ride, so it’s better to avoid such challenges altogether and instill security from the employee number 1. Everything that’s happening in the organisation is CEO’s responsibility and if she/he doesn’t set a healthy tone from the day 1, it’ll be hard to teach people to follow the practices, if they know even CEO doesn’t walk the talk.

I recommend all-sized businesses to look for the help of security consultant as soon as it becomes affordable. I wish more companies realized that asking for a few hours of consultancy won’t ruin their budget, but can have tremendous ROI. It can create a baseline upon which they can build their stuff securely from the day one and avoid costly refactorings or breaches in the future.  Chances are that if you give it a thought, you’ll remind yourself that you personally know some security passionate who’ll be more than happy to support some startup free of charge in exchange for business experience. She/he can help you ensure that products are well secured, so people in need should reach out to their social circles and ask for help as soon as possible. It costs them nothing, and even if they find a kid who’s been studying appsec for barely 6 months and can work for you only part-time, it’s still better than doing nothing at all.

I’m writing this to demonstrate two important things we don’t pay enough attention to. If you’re a security specialist and someone is asking you for advice, you should emphasize the importance of starting early. Because if you eventually end up joining that company in the future, you don’t want to start from scratch and waste your energy on solving problems that could’ve been prevented from happening in the first place.

The other one is that when you join the company, expose yourself as soon as possible. Don’t close yourself in your office focusing solely on technical aspects such as deploying monitoring and pentesting the infrastructure. Go out there, and show people that you exist. Allow them to notice you, and give them relevant resources as fast as you can. Provide them with books, articles, tools, guidelines, checklists, procedures so they can already start applying it in their day to day work. Thanks to that the improvement will be happening in the background, when you get back into your zone focusing on other things.

Outline SDLC/NDLC improvements

Security should be perceived like any other cost of running a business

Security shouldn’t be seen as an addition to the product development. It’s as regular part of a business operations as anything else, especially when we’re talking about companies that develop their own software.
At software companies, ensuring security should be considered as a part of Quality Assurance, not only because security triad mentions Confidentiality, Integrity and Availability out of which 2 are heavily linked to the product’s quality. So there is that, but also nowadays customers demand products to be safe for their personal usage and professional usage, because they don’t want to buy a service which may have negative impact on their business operations. We’re living in times where we’re all connected to each other like never before and not a single company can exists on this planet without affecting others in one way or another.


Although it may sound obvious to you, it’s not you who I’m concerned about, because we – security professionals – can’t do anything on our own and the perception of all parties involved matters. You must instill security into organisations DNA in such a way that people truly understand what it is and how it matters, because it doesn’t really matter if you have triple-firewalled PC with a personal guard watching over your computer when you go to the toilet, if there are employees who think it’s fine to download pirated games on their corporate laptops.

Also, middle-management is much more eager to spend resources on security, when they perceive it as a regular, necessary cost of software development. There will never be enough money and time to invest in “additional” activities, so you must rewire their dictionary. Security is often called a no-ROI time-waster which adds complexity and slows down development process, so not only security itself costs a lot, but it also makes other things more expensive.
Unless you explain how and why security is important you may have hard time pushing security related changes into existing SDLC processes, and that’s fair because everyone has their own work they’re ought to protect. That’s something you got to really understand, because most often at the workplace importance and urgency, don’t come from  inner virtues and passions, but from the actual business impact. So that’s something you must comprehend to shift your mindset and help everyone across the board understand what impact may insecure product have on your business, because except of us, no one is there to do security for the sake of doing security.

 

Hold them accountable to high standards, but keep your expectations low

Settle down on how much resources can be dedicated on security improvements, bugfixes and alike.
Discuss how many hours in each development sprint can be dedicated for security and how much free bandwidth does engineering have for potential unexpected security patching. Write it all down in internal documentation system or some other place that allows you to have an official proof that you had those discussions, so that no one can claim that you’re expecting them to do something they hadn’t agreed upon and twist out of the commitment. Each big goal is achieved by making many small steps, and altho it may look like some things should be done all at once, it’s most often not the case in real life. If you properly dissect your projects into smaller tasks, you’ll realize the value of small incremental changes and that big projects not only suck for time management, but they also tend to create a lot of friction with coworkers.
Focus on small but constant improvements, so you have the big goal in back of your head, however you don’t expect people to deliver it all at once. Not only it’ll make execution your projects on time more feasible, but it’ll also reduce the stress and boost team’s morales when they see 100% execution of a small task, rather than 0.1% progress on a huge project.

Let me make one remark here tho, because you really need to be wise when creating your expectations and demands. It’s not reasonable to expect business to stop all money-making activities and focus entirely on security for a few days or weeks to fix identified vulnerabilities. Use risk management to help business operate and help ensure it’s longevity instead of expecting impossible.

In my experience, it really makes a lot of sense sense to establish a fixed amount of resources that will be spent on ensuring security in each product’s release/sprint.
Sacrificing 3% engineering resources each day, is less painful than telling customer that you won’t deliver a mission critical feature, because you had to stop all your software engineering activities, caused by your security department having this unreasonable request of focusing solely on security for a next couple of weeks. Customers care about security, but not that much, to let you lag on service delivery.

Build secure SDLC

Security is more cost-effective if you start working on it at the earliest phase of SDLC.

Old tried and true, isn’t true anymore. The common practice of building a product and throwing it at a security team doesn’t scale anymore. Given how much code we produce on daily basis, it’s increasingly more expensive to not instill security in early phases of SDLC. At current pace we can’t afford waiting will last phase of SDLC, because a need for potential refactor of two weeks of code would come with dramatic costs.

Securing the whole workflow drives very tangible long-term improvements, because to me it’s less about catching issues earlier than it is about education that ultimately is something we’re looking for. Developers who’re constantly exposed to security work, will memorize more and more of it, keeping safety in back of their heads and  allowing them to fix the issues even faster.
We don’t want to see same mistakes over and over again, and unfortunately that’s something I still see at most companies all over the globe. Although the software engineering world moved forward a lot, security practices are still holding it all back and we haven’t globally addressed the basic issues that are so trivial to be remediated. It’s all about mindset and it’s all about moving the responsibility to the left and then making sure everyone is capable of taking ownerships of it.

 

While I get it that approach of black box pentesting was somewhat practical in the past, – been there and done that – nowadays most innovative software is too complex for security teams to secure the product in just few days before it hits production. There must be a whole lot of things done around it, which we’ll discuss in DevSecOps chapter later.

Surely there are small software houses with senior, security-savvy engineers where it’s practical to build a tiny product and then deliver it to security testers, because they cared about security while writing their code. But during my whole career having had worked with thousands of engineers from dozens of companies, I can name only a handful of such senior level of security-savviness so hoping that you have people who are somewhat competent in security isn’t the smartest thing to do.
Actually, hope rarely is a good strategy for anything in life. It’s good to have, but it’ll take you only this far.

However, if what you’re doing works for you, your company and your customers, then keep doing it. I want to emphasize it once again, that I’m sharing yet another perspective that if you feel a need to, you may want to try out. So while I’m advocating an approach of injecting security into whole software development life cycle, I realize that it is not a silver bullet and it may be too expensive for you at the moment. Yet still, I believe that 1% is much better than 0, so trying something is better than sitting stale and missing the right point when you were supposed to take action.
My recommendation always is to get involved in product design phase and keep an eye on the product throughout the whole development process. 

It’s all about cloud and dirt. About having the high level vision and long-term roadmap as well as doing what needs to be done to help you organisation achieve the goals.

Social Skills For Information Security Professionals: The Preface To My Book

On my motives for this book

How and why – I believe – can my story make your life easier

It’s been roughly 11 years since I’ve started commercially working in IT, out of which 7 were profoundly dedicated to InfoSec, a field in which I truly believe there is a lot yet to be done and that each individual can make a difference by their contributions. Similarly to the careers of so many of us, I’ve made a plenty of mistakes that had put my career at risk, significantly slowed down my growth, significantly lowered the income, as well as had negatively impacted my health and personal life. Although making mistakes should be an expected part of any worthwhile career, I had certainly not expected that along the way I’ll taste so many different flavors of life.
I’ve had my ups and downs, but I always tried to ensure that whoever was involved, came out with something beneficial to them. Despite having good intentions in my heart, not always was I successful in demonstrating that well. To me, everything I’ve been doing was always about bringing value to others and being the most productive person in the room, long before I have realized that I’ve had been doing it all wrong and my hunger for success was my biggest obstacle. But as the saying goes, “obstacle is the way”, which is why I’m grateful for all of it, and I really want to share my experiences with others, so they can save themselves some trouble and get smarter faster than I had. I wish I’ve had a resource that would guide me through at least the basics of human interactions and effectiveness in the business world. So here it comes. A book that I wish someone else gave me 11 years ago.

I want to be really upfront and transparent with you. Although the companies I’ve worked for were very satisfied with the outcome of my work, to me it came at the cost of my professional and personal relationships. Without any doubt, I can say that because of my stubbornness and improperly directed hunger, I’ve wasted a ton of my potential as well as burnt some potential in others. And that feeling sucks. Realizing that while chasing greatness I’ve had a negative impact on a quality of life of a few people around me, as well as looking at my own life and noticing how much health and energy I wasted – it just sucks. But it sucks in a different way than most things in life suck. It’s not about discomfort this time, but about an actual pain, because while I’ve got compensated quite fine for my around the clock grind, I’ve forgotten about the most important currency we have access to in our lives – time and health. If you’ve got good health and you’ve got time, you have all the resources necessary to makes something great happen. Assuming obviously, that you’re resourceful and can actually understand the value of these powerful two. That’s what I want to be the leading point of this book, i.e. how to achieve your goals quickly, yet without compromising quality of yours and others’ life. I respect your time, which is why I wanted to keep this book as concise as possible, cutting out the fluff each time I’ve noticed any. If this book takes you 2 hours to read, and it saves you as little as 1 day of your life – I’m all set. My mission is accomplished and I’ll feel good about it, because there is no bigger mission than saving lives. This is one of the reasons I’m publishing this book for free. I’m making fair amount of money on selling my time to the corporations, and I want these lessons to reach as many people as possible and help them preserve their time and health. I can make money by other means, but the opportunity to help people improve their health and relationships is so rare, and so huge, that I couldn’t let myself to agree for commercial publishing. I’ve been sharing my knowledge for the past 5 years all over the Internet, at conferences and meetups; and those few voices generous enough to share with me that I’ve helped them improve their lives, are the biggest reward one can get for their work. That’s what I hope this books will do for you – help you achieve your goals at lower costs of all involved stakeholders at all facets of life. I don’t want to monetize on this book. I want you to learn from it, and then for you to monetize newly acquired knowledge by improving as a professional and getting compensated well for your effort.
You don’t owe me anything and I don’t expect anything from you. You’ve already given me enough than I’m audacious to ask – your time and attention. Thank you for that, and if you still want to do something for me, then please share your experience and knowledge with others. Help you peers, show them your perspective and help them grow by exposing them to various point of views. Pass your knowledge to others, so they have it easier than you had. To help them avoid the mistakes you’ve made and so that they can save their time and use it to build something bigger or experience other thing life has to offer. Standing on the shoulders of giants. That’s what it all is.
I guess at this point you can already smell how much I dislike wasting time and reinventing the wheel 🙂

How and why – I believe – my story can make you avoid personal and professional suffering

Infosec is a stressful job and if not managed properly leads to unhealthy situations which surely can end up with a long-lasting burnout. Burnout is one of the most painful experiences in the life of a professional, especially a good one who is self-aware enough to realize how much of a potential they had and how it just got destroyed. There are many critics saying that the job-related stress in industries such as IT isn’t worth discussing, but I call that a dangerous misconception. You couldn’t get more wrong in thinking that we’re not under high pressure. InfoSec is one of those industries where many things are totally out of our control, and you can’t really sleep well – ever. Many of us got so engaged into the work we do that we started compromising other parts of our lives, introducing unhealthy imbalance. Precisely such imbalance led . So I can relate to all of us, who had experienced tough times. That’s one of the reasons I believe in this book so much. It’s not that it contains any secret knowledge, or that I’m such an egocentric writer. Heck, I’m not even a native speaker english speaker, so I realize my shortcomings, yet I am still ready to take the heat, because I believe in its value. I believe that this book can help – at least to some extent – my InfoSec friends who have struggled, struggle or will struggle with the challenges I’ve been struggling for many years. I hope this book answers some of the questions we ask ourselves and will turn out helpful especially to those of us, who have nobody to turn to for a practical and non-judgmental advice. Writing the book has certainly help me in understanding some concepts better and instilling them deeper into my mind, so I have the answers handy whenever I need them. And I need them pretty much on daily basis, so having this handbook on my computer allows me to stay in sync with reality and remain calm and humble.  

The tough experiences had made me who I am today, and with many bad outcomes, I’m getting more and more comfortable with helping others avoid my mistakes. Losing relationships, not taking care of my health which resulted in life-long illnesses and daily pain which decreases the quality of my life, had all contributed to the process of reinventing myself. Moments of the truest joyfulness were these where I’ve learnt that something can be done better. That I can do better and I can be better to other people. It’s thanks to those moments that I’ve used to reinvent myself, I’ve been able to achieve long-lasting fulfillment.

I know I’m starting to sound meta and all that corny stuff, but I decide to still leave it here as I’ve met people who will get to feel the hope again while relate to my story. I’ve got good news for you though. Only the foreword contains so little substance.
Please feel free to use this book whatever way you like to. You can read it as a regular book in its entirety or using it as a reference handbook, with easy to navigate index which allows you to jump into specific questions and answers.

Almost nothing worthwhile comes without pain or some sort of suffering so I’ve came to the point where I accept my mistakes and allow myself to live without blaming myself too much for making them. I advise you to look at things similar way, because holding to the past in which we weren’t as smart and wise brings nothing good. Looking at the future as a blank page, allows you to approach things differently and avoid repeating the old mistakes.
In the book, I”ll be guiding you through subjects that are very subjective and focus mostly on emotional intelligence and social skills, which can’t be as accurately measured. So you might feel like I’m yet another bozo, but you need to open your mind to fully benefit from it. I promise you that nothing in this book hasn’t been thoroughly tested, and each and every single chapter you find in this book describes lessons learnt from mistakes I’ve made personally in my career. I’m never talking about others, about things I’ve only read or heard about. Everything has been battled tested by yours truly and I believe most of it can be easily replicated into most working environments. It worked for me with minor contextual adjustments while working for companies from various countries on two continents with organisations ranging from a small services startups from Silicon Valley, through public institutions in Poland, to hundreds million dollars big corporations.

You need to sacrifice the present for the better future, but it doesn’t mean you need to sacrifice as much as I’ve had to. I’ve learnt a ton and I want to use that knowledge to help you make your professional life easier. I want you to be more effective and productive than I used to be all those years before I started taking the human aspect more seriously.

Understanding these concepts can potentially enable you to see a bigger picture and gain richer point of view. Please bear in mind that nothing is set in stone and that my experiences may be different from the things you’ve had a chance to experience in your career. So to limit the amount of anxiety and misunderstanding, let’s create a healthy narrative for this journey of ours. I want this book to be an inspiration for you, showing you yet another perspective of someone who gotten his hands dirty, not a predefined set of rules one must follow.  Use it as a doof for thought, a content for consumption and a spark to initiate something bigger and adjusted to the to culture of your organization and your personality. Your personality matters. Just because something had worked for me and is indeed a sane way to do things, doesn’t mean you’ll want to follow the same path. Things that come to me easily now may come hard to you, and that’s all fine. We are different, so embrace what’s best in you and use that to achieve what you want to.

How to squeeze maximum value out of invested time in reading this book

This book isn’t an ideal picture of the world. It never intended to be. It was meant to show us ways in which we can be more practical and effective. To show you how we can abandon the fears, imposter syndromes, anxiety and stress – or at least reduce it significantly, by small tweaks in a way we operate on daily basis. I want this book to be practical, so I recommend you to read this book slowly and don’t rush into next chapters. Please read a chapter and give yourself some space to reflect on it. Try to remind yourself a situation to which a chapter would apply and outline counterarguments to what I’ve written. Then find a right balance for you and find the best way for you to navigate through life. I’m not right, and you’re not wrong. We’re both doing our best, and sometimes the best solution is in the middle of two perspectives, of two totally different individuals. You do you.
After all while we’re expected to bring value to the business and help it make more money so if you’re still employed, then apparently you must be doing something right! However, regardless of how much we like or dislike our job currently, we can make ourselves like it more. We can make others like us more and we can reduce the anxiety of a whole system.
But for that to happen, we must improve our social skills, especially communication skills at scale.

I believe that security professionals can’t achieve their greatness at the workplace, if they’re not being actively supported by all stakeholders across the entire organization and if other employees don’t feel ownership for the organization’s safety. Security just must one of the core values of corporate culture. Each time I have joined an organization, where security professionals wanted to do everything themselves, they miserably and painfully failed shortly after.  Fighting a broken security culture without any support from the top leads to burnouts for InfoSec folks and creates general anxiety, irritation and a toxic atmosphere within an organization. No one wants that to happen, yet so often we end up in exactly such situation.

Right, but what about Secure SDLC you may ask? To me Secure SDLC is more technology centric, while DevSecOps is more human and culture centric. I may even write a book on secure SDLC one day, but we have a lot of great content on that matter already, so it’s not a priority by any means. To me, helping people understand the DevSecOps culture is much more important task, although they are very powerful couple, and I believe in the long run, one cannot exist without the other. I would even say that many companies have magnificent SSDLC, but it could be so much better if the operators understood that each business, is a human business first and you can boost whatever you’re doing by involving more people and making them care about it.
I’ve met many people who understand how to implement SSDLC principles into their organisations, however not many know how to build the DevSecOps culture which can bring their SSDLC or whatever they’re doing on the totally next level.
I’ve spent over 5 years working on implementing DevSecOps culture at the organisations I’ve worked at, because I believed that with so limited resources doing things together is the only way to go. We all hit a point in which we can’t scale anymore, which is why we must seek help of others. And to get such help, it’s good to provide it first. Be the leader people will happily look up to and many doors will open. And by working all together we can do much more and do it much better.
SSDLC is fabulous piece of art, and I wish more companies adopted it since 2002 when Microsoft officially announced it. I really with, because we’d be in a completely different shape as the whole industry. But we haven’t so we must add something to it, that will fill the gaps with a work that doesn’t cost much every single one of us. Collaboration and empathy is something that’s not that complicated or expensive if we only decide to take one step forward each and every single day.
With a right attitude the culture is something that can be created in the background, while we can use our technical competence to enhance our SSDLC workflows and incrementally improve resilience of the organisations we work for.

I hope the lessons shared in this book will save you – and everyone around you – a lot of anxiety and trouble. I wish I had access to such a resource when I was starting out, which I believe could’ve helped me prevent the damage that has happened otherwise. It’s never too late to learn and improve, so I’m still extremely grateful for an opportunity to have experienced so many things and that now I can share it for benefit of others. I hope this book helps you navigate through social interactions with lower stress and more fruitful results and although this book summarizes the most important lessons learnt over the past decade, I’ll be still happy if it saves you a single day of your life.  

Let’s get started already! 🙂

QA Summer Fest #1 – Miquido

Miquido,  fantastyczni ludzie, fantastyczna organizacja I mega atrakcyjne biuro!
Na wewnętrzne zaproszenie miałem przyjemność występować na pierwszym wydarzeniu z serii QA Summer Fest, więc nijako jestem z tego dumny 🙂
Spotkałem się z niesamowicie przyjaznym przywitaniem oraz pożegnaniem, wobec czego jeśli kiedykolwiek usłyszę “Miquido”, będę mieć tylko i wyłącznie dobre wspomnienia.
Sala konferencyjna była dostępna już na godzinę przed pierwszą prelekcją,  dzięki czemu każdy mógł się komfortowo przywitać i znaleźć sobie przyjemne miejsce do brania udziału w wydarzeniu. Ciężko było mi dostrzec choć jednej osoby, która by się nudziła, mimo, że przyznaję się bez bicia – przeciągnąłem swoją prelekcję mocno. I trochę za mocno i wiem, że uczestników wymęczyłem, jednak “connection” które czułem z grupą, sprawiło że prelekcja przemieniła się w przyjazną rozmowę na tematy życia codziennego w branży IT.
4 października po raz kolejny będę miał szansę spotkać się z ekipą Miquido w ramach mojej prelekcji na Mobiconf. Coś pięknego, dzięki jeszcze raz za gościnę!
Podrzucam jeszcze link do prezentacji, o który parę osób pytało:

SJSI Quality3D meetup #3

Paręnaście dni temu zdarzyło mi się pojawić na https://www.facebook.com/events/225878038117535/ i niestety dopiero teraz znalazłem chwilę, żeby stworzyć podsumowanie.
Przy pozytywnych doświadczeniach generalnie tak jest, że nie ma za wiele o czym mówić. Inaczej wygląda sytuacja gdy jest negatywnie i chcemy się tym podzielić, żeby wyrzucić to ze swojego systemu i iść naprzód, upewniwszy się wpierw że każdy jest świadom naszych cierpień 😉 Tu cierpień nie było ani odrobinę, przez co chwilę zajęło mi napisanie podsumowania.
A tak poważnie, było dobrze, nawet bardzo dobrze.  Miałem szansę spotkać się z bardzo przyjemnie aktywną grupą, z którą mogliśmy prowadzić dialog, zamiast prawić jednostronne prelekcje.
Taki format, real time Q&A odpowiada mi najbardziej, bo wtedy czuję, że nie tylko mogę poznać ciekawych ludzi ale też wnieść wartość przez proponowanie rozwiązań do realnych, kontekstowych i indywidualnych problemów.
SJSI organizuje ostatnimi czasy bardzo ciekawe wydarzenia, na które zapraszają ludzi z wielu dyscyplin, by ci podzielili się swoja wiedza i doświadczeniem. I dokładnie w ten sam sposób sytuacja miała się z moim wystąpieniem. Zostałem zaproszony i bez chwili zastanowienia krzyczałem “TAK, TAK, TAK!”. Możliwość dotarcia do nowej grupy osób ze swoimi ideami, pomysłami oraz gotowymi recepturami rozwiązań do szansa której nie mógłbym odrzucić.
Jestem wdzięczny za możliwość docierania ze swoja wiedza i doświadczeniem do innych. Za każdym razem, podczas każdego występu, mam nadzieje na dostarczenie jak największej wartości ludziom którzy zdecydowali się zainwestować swój czas i pojawić się na wydarzeniu by słuchać własnie mnie, Jestem szczególnie wdzięczny za mile przywitanie oraz za interakcje podczas prelekcji.
Mimo, ze początkowo byłem myślami gdzieś indziej przez realizowany wcześniej projekt, to po 5 minutach już byłem all-in i totalnie pochłonięty przez interakcję z uczestnikami. Było dobrze!
A teraz czas na linki o które pytaliście.
Książka:
Prezentacja:
Artykuł o tym jak przebić się do branży security:
A w skrócie, event był o:

“Najlepszych rzeczach, jakie możesz zrobić dla bezpieczeństwa Twojej firmy w ciągu najbliższych 3 lat”

Firmy, ich pracownicy oraz cała społeczność IT jest zakłopotana i lekko zagubiona w ogromie zagadnień związanych z bezpieczeństwem organizacji. Jest tyle szumu informacyjnego dochodzącego z każdej strony, że ludzie nie do końca wiedzą, którą drogą pójść, aby zwiększyć bezpieczeństwo swojej firmy. Czy powinni testować manualnie czy automatycznie, czy powinni zamawiać usługę pentestów, czy używac programów bug bounty, czy powinni trzymać swoje dane w chmurze czy w klasycznym centrum danych.
Podczas niniejszej prelekcji postaram się odpowiedzieć na te i wiele innych pytań – schodząc do poziomu technicznego. Moim celem jest podsunięcie Wam pewnych pomysłów i gotowych rozwiązań, tak abyście mogli skupić się na realizacji istotnych zadań.

oraz o

 “Testowanie najpopularniejszych błędów bezpieczeństwa – rozwiewamy mity o trudności pracy jako bezpieczniki i pokazuje że może robić to każdy z Was.”

W świecie bezpieczeństwa krąży legenda o tym, jak wyjątkowym trzeba być by zajmować się testowaniem zabezpieczeń i ochroną organizacji.
W rzeczywistości – uwaga, uwaga! -wszyscy jesteśmy ludźmi i jeśli coś udało się zrobić jednej osobie o podobnym do Ciebie profilu, to możesz to zrobić i Ty.
Podczas półtoragodzinnego warsztatu pokażę Wam praktyczne narzędzia oraz przybliżę sposób myślenia konieczny podczas testowania bezpieczeństwa, dzięki czemu – niezależnie od obecnej profesji – będziecie w stanie wgryźć się w temat testów bezpieczeństwa, testów penetracyjnych, audytów bezpieczeństwa i tym podobnych.

InfoSec Career Paths vs Programming Skills – The Basics

On Peerlyst, in my Q&A session, Eric Geek‍ asked:

Is being a great developer vital when choosing information security as a professional career?

My answer below:

Beneficial? Yes.
Necessary? By no means. Demand for development skills in infosec is raising, but the demand for general infosec specialists is growing even higher.

I know many fantastic security professionals, who just hate programming. They’ll code a bit to help themselves, to build some simple automation for their tasks, but they’d never write any serious application.

The market for infosec professionals is so wild, that it’ll eat almost anyone with any interest in security and some technical acumen.

Software engineers can easily become information security specialists

… and they bring a lot to the table, for organisations that need that kind of skill set.

The work required for software engineer/programmer to become security specialist will vary a lot depending on the person and their existing skills, aspirations and predispositions.

If you are a software engineer, then I would recommend to learn more about application security and then move into secure software engineering roles. While in that position, your goal should be to gain exposure to technologies and security processes. This will make it easier for you to switch between other professions within the cybersecurity industry.

If for example you’re a software QA engineer and you know how to test software, it doesn’t take much to start including security tests in your day to day work. It will allow you to realize after a couple of months that you’ve gotten the grasp of quite a few security issues!

If you’re a network engineer, then it makes sense to learn more about infrastructure and network security in order to move into positions such as network security engineer, incident response engineer, or a network penetration tester.

This approach should help you if you want to transition into cyber security at low cost and low anxiety. It makes it easier to make that transition, because if you have a solid background in building something it will come easier to you to figure out how to break it and secure it.

If you’re comfortable in a given specialisation, you won’t feel scared of the amounts of new knowledge you’ll need to possess and this will lower stress to ease you into the learning process.

So a software engineer who wants to transition into security role, should try applying security principles to whatever they’re currently doing — try to learn how to break the things they’ve built, and then how to make them more secure and impenetrable as possible. If you reiterate enough, you can become a security-savvy engineer who can easily add ‘security’ in front of their existing job title and becoming a security specialist in any given field.

I would suggest adding some good eye opening resources to your knowledge base. One that holds value for all types of security operations is learning about basic Security Architecture Principles. And then learning more depending on which fields of cybersecurity you want to explore.

Here are some great materials for Web and Mobile Applications:

  • OWASP TOP10
  • OWASP Application Security Verification Standard(ASVS)
  • OWASP Security Code Review Guide
  • OWASP Web Applications Testing Guide
  • OWASP Mobile Testing Guide

Network and Infrastructure Security:

But the most foolproof and effective methods of learning security skills to me is doing the following: google stuff out. Start doing some fundamental research in your craft and google is your best friend here, and always will be. Sooner you learn the art of googling, is better because we use it a ton in our day to day work.

If you’re writing code in C++, then google “C++ security vulnerabilities”, or “writing secure code in C++”. If you’re deploying apps in cloud, such as AWS, then google “how to secure AWS applications”, “secure deployments in AWS” and so on. Learn as much as you can from search results and from the latest news, this will expand your security expertise as time goes by.

This way you’ll learn security skills relevant to what you’re currently doing and keep up with the latest cybersecurity trends, which will allow you to live and breath that knowledge and put it to practice in your projects.

You can become valued security professional from any IT specialization

I often get a question on how to become a security professional. And my answer is – by becoming a professional in any other field, or by working your way up from anything you’re currently doing. Reverse engineer requirements from job offers in your area and learn what they want you to know. Then strike at them as soon as you feel comfortable with your skills. Research & reverse engineer job offers & learn & practice & go on interviews & understand what you were missing and why they haven’t accepted you & learn the missing pieces & rinse & repeat until you get a job.

Appreciate the journey and don’t underestimate the value of having a varied background, do it all at the beginning because you’ve got time.

I started my adventure in IT from the very bottom, working as a computer technician, network admin, web programmer, and system administrator. After many years, I got involved in security. I do not regret the time I spent in previous positions because taking an indirect path provided many valuable experiences, all of which gave me perspective. My range of experience allows me to understand the problems many employees face, enabling me to make better decisions for the companies and teams I work with. I believe the security industry could benefit greatly from more diversity

However, if we’re considering a position where you have zero experience in security whatsoever, but have experience in other fields of IT, then I recommend becoming an expert in a different field. Start applying security concepts to your field of specialization. This has worked for so many talented professionals I know. Too many people want to get into security without prior experience in anything IT related. This doesn’t make most of them very valuable professionals because they tend to make myopic decisions without considering business context. Security is merely an addition to business operations, designed to support its longevity. It doesn’t exist on its own.

You can read pentesting and bug bounties blogs, but pasting random payloads without deep understanding will prevent you from contributing much to your organization. Dive deep into anything you learn, stay curious, and enjoy ‘expert’ status in a few years.

Here are a few viable and popular career options:

Web App Security TesterSome skill in coding is good. It’s not necessary, but it is beneficial and it’s usually what separates wannabe experts from true experts. Learn how software stacks work and get a handle on web programming languages like Java, PHP and their respective frameworks. To break something and improve its resiliency afterward, you should understand how it all works. Once you review all the OWASP resources, you’ll know what to do next

Network SecuritySimple bash/perl/python/ruby coding if any. Create a local lab network consisting of various components. Deploy services like LAMP (Linux, Apache, MySQL, PHP) stack and research how to secure each element. While building, study what issues can arise during configuration and maintenance so you know what to avoid and how to test them when sysadmins hadn’t the time, interest or knowledge to do so. Then, focus on PTES (Penetration Testing Execution Standard) Technical Guidelines to discover ways in which penetration testers and hackers can attack your network. Reverse engineer their methods to build proper defenses against future attacks.

Compliance and AuditingZero programming skill required for most roles. Learn about underlying technology and business models. You want to understand how businesses operate so you can protect them and ensure new regulations don’t hinder company innovation. Grab some good business books and gain business exposure by learning from executives and managers with real-world experience. Study industry best practices, like those from the Center for Internet Security, as well as regulated standards like HIPAA, PCI-DSS, DISA STIG, ISO 27001, SOC2 to understand how to make your organization compliant without negatively impacting productivity.

Cryptographer/CryptoanalystDepending on a chosen niche, coding may be just an addition for tests of implementations, protocols and algorithms cracking. If you want to become an expert in this field, I recommend attending a university with strong mathematical and cryptography programs. This is a fascinating field that requires prior and substantial mathematical knowledge, so if you go through heavy math, learning to code will be your least worry 🙂

Security ConsultantDepending on the context, most roles require zero coding, some require some. This position will help you gain experience working in IT or IT security, so you can understand the business and broaden your horizons. If you decide that you want to stay in consulting, research what big companies are doing, technology they use, and regulations they’re subject to, then learn how to manage these for them.

Vulnerability ResearcherAll-in or ZERO. This narrow specialization requires focus in at least one field. Become proficient in at least one programming language, framework, and operating system. Then focus on a narrow set of functions in a given product or service. Examples include studying assembly, C programming language, learning how video transcoding works, and identifying weak spots in a library such as FFmpeg. Zero coding is required if you want to be a bug bounty hunter, who keep calling themselves “vulnerability researchers”

Software Security Expert – Software engineers often become security experts. Be proficient in at least one technology stack, then apply all relevant security knowledge to making products safer. Strengthen security across your organization, responding to the demands of your colleagues and customers.

If you want to speed up the process of becoming values security professional, pick technology that truly interests you and learn as much as you can about it. So instead of being Web App pentester, become a Node.JS security expert. Be a specialist, not a generalist. Go for a narrow niche. Find something that sparks your curiosity and become passionate about it. Know things only 0.01% of people using the technology knows and your pockets won’t be able to hold amounts of money companies will pour into it 🙂

The most important advice here is to look for employment as soon as possible because nothing can beat the quality of learning you get on the real job. It’s the actual job and job market that shows you what is required and what is not.

Almost ZERO programming experience required for Penetration Testers

Don’t get me wrong, pentester who knows how to program and code is invaluable, but some pentesters are such great manual testers that they will find a great employment no matter what. Despite the current state of pentesting in US where actually cool stuff is happening, you still have 95% of countries who’re a decade behind in terms of their cybersecurity posture, and in there all you need is to study OWASP Testing Guide to fill your pockets big time.

Let’s consider a few scenarios and then jump to job specific recommendations.

If you already have some security experience, then check out a few renowned books that are highly rated on Amazon with the title containing word “Pentesting” to build your foundation. Then go for an Offensive Security’s lab and certification – OSCP, which as of now is the most respected entry-level certification for penetration testers. Consume as much content as you can, but don’t allow yourself to get lost in the universe of theory. The best pentesters are those who put their knowledge into practice and get their hands dirty.

If don’t have security experience but work in other IT fields, then the recommendation is for you to become an expert in a different field and then start applying security concepts to your field of specialization. That route worked for many great people working in the industry that I know. If you’re a Java programmer, study how you can test applications written in Java. If you’re an IT OPS engineer deploying services in the cloud(AWS/GCP/Azure) then learn about potential security issues and learn how to pentest those services. Learning will come much easier if you have the proper background.

If you haven’t ever worked in IT, but want to work in security, well this one is tricky and hard because general security isn’t an entry-level role. Too many people want to get into security without prior experience with anything IT-related, which doesn’t make them very valuable professionals because lots of decision they make are myopic and don’t consider business context. You can get easily get excited reading pentesting and bug bounties blogs, but as long if you’re just pasting random payloads without deep understanding of a matter, then you’re not contributing much to your organization. Same way you won’t get a sixpack by reading about pushups, you won’t become a great penetration tester without going into the field and testing stuff.
So go deep in anything you learn about, and enjoy ‘expert’ status in just a few years.

And now let’s take a look at some of your options when you’re completely fresh to the field.

Web/Mobile App Pentester  – Learn how to code. It’s not necessary, but beneficial and that’s what usually differentiates expert wannabes and true experts. Learn how software stacks work to get a grasp of web programming languages such as Java, PHP and their respective frameworks. To break something and improve, then it’s the resiliency afterwards you should understand how it all works. It doesn’t mean you must be a guru software engineer, but you can’t go wrong knowing the basics.
Once you’ve completed all the resources from OWASP you’ll know what to do next.

Network/Desktop Apps Pentester – Create a local lab of a network with various components in it. Deploy some services such as LAMP(Linux, Apache, MySQL, PHP) stack and then google out how to secure each of those elements. While building, study what issues can arise during the configuration and further maintenance, so you know what issues to avoid and how to test them in the future in other environments where sysadmins hadn’t had time, the interest or knowledge to secure their instances the way you could. Navigate to PTES (Penetration Testing Execution Standard) Technical Guidelines and see what are the ways penetration testers and hackers could potentially attack your network, then reverse engineer their attack methods and build defenses so they attacks no longer work.

Specialized Pentester – Pick one technology and go as deep as you can. So instead of being a Web App Pentester, become Node.JS Security Expert. Become a specialist instead of being a generalist and cut the learning process in half or even more. Find something you’re curious about, learn more about it, and become passionate about the field, put in a few solid years of dedication, and you’ll get whatever you want to have. (Well, not precisely everything you want, but you get the point)

Red Teamer – All of the above recommendations apply including social engineering and physical security attacks. You may not have the technical predispositions to be a great web pentester, but if you have been gifted with empathy and social skills then you can still achieve a lot!

There are hundreds of blogs of people who documented their journey, and I recommend you to look into real world examples of people who’ve moved into a pentesting career. Learning from the successes and mistakes of others is very cost-effective. Also, I’ll recommend you a bulletproof method of finding a job as a pentester. An importance most people don’t realize:

  • Find a few dozens of pentesting job offers in your area
  • Extract the most common requirements, both high level and detailed technical skills
  • Know what to study and what employers really need
  • Don’t waste time on learning everything. Learn the minimum possible to get the job and be a valuable team member. From there your career is highly malleable, you can adapt to what your organization needs you to do.

So yeah, you can flourish in the infosec field without having more than one week of study in programming. The market is the ultimate judge. Some companies require programming skills as a must-have, and some don’t care. Find what suits you best and keep on rockin’!