Browsed by
Category: Security

Which knowledge management tools should we use?

Which knowledge management tools should we use?


There are several methods to make managing knowledge more common practice in each team.

Knowledge base

This is the most basic tool for managing information. One of the knowledge management principles mentioned earlier is to storing and sharing. Knowledge base satisfies them. There exist many sophisticated software tools to manage it and almost everybody broadly knows the biggest one. Wikipedia is probably the most major open knowledge management tool on the internet. You can use a custom library to configure your Wiki website. It is crucial to structure knowledge in this repository respectively to organization needs.

Job rotation

Another very common technique to ensure that many people would know what to do is changing places. It consists of assigning an employee to different job positions or different organizational structures over the time. It lets to share knowledge about a variety of duties over the team. It also can help to reduce boredom and stress level of team members. However, some positions need a specialized knowledge which is very hard to teach other people. So it can be not easy to introduce new people, but it may be beneficial for him and all team knowledge.

Most of all let’s make sure that employee is at least a little eager to learn new thing. Otherwise, the role of team leader is to build this desire.


A lot of tasks we do in our everyday work is schematic. So we can automatize them in several ways. There exist many services to automate your daily workflow. For example, you can create a trigger to handle automatically the invoices that you get on mail to copy it to appropriate folder and set up an alarm to remind about it.

There are plenty of possibilities. You can create a script, use an on-line service or whatever you can imagine. It can speed up your work for sure. But you may ask where is the knowledge managing in this. Your knowledge could be processed by some automatic processes, which you can manage and share with others. That is management.


The other type of learning in work could be mentoring. It requires that a more experienced team member take care of the person who needs some more knowledge. However, it not means that this mentor should make a lecture for him or some other kind of workshops. It is only needed that experienced (in some scope) worker would be open to answering to questions and willing to work with the less experienced man.

Standup meetings

In Agile teams there is a practice to meet every day for about 10 minutes and tell your whole team what we did last day. This habit can increase the broad knowledge about team and responsibilities. Also, it can help with the problem when we have some question to the particular part of the system, and we don’t know who is responsible for it. It is not exactly the knowledge transfer, but it may help to spread the information where we can find the knowledge about some topics.

Code review

Another form of sharing knowledge about tasks and functionality which particular employee is involved in can be cross checking the code. According to this method, every change made by one team member should be check by somebody else. This practice could be extended to style, security, guidelines checking and improving code quality.

Keeping consistent style and rules

Referring to code review, following one consistent standard of writing code can be valuable for project quality. It may decrease the time needed to read the code. Therefore the time of learning the new code, in uniform standards, can be considerably reduced. Some tools are helping us to keep a consistent style. For example, JSLint or StyleCop are tools with a defined set of rules to check the proper form of code. They can be used before developer tries to send the code to the repository and inform him about all violations.

There are also many ready and reviewed style guidelines on the internet. They exist for different languages and can be easily found on the internet.

Tests as a documentation

People tell that tests are the best documentation. There is a grain of truth in this sentence. If somebody looks on tests for some functionality, in most cases he can easily see what is done by this class and what is the test cases or use cases. This is another method to simplify maintaining and knowledge transfer.

Bragging about knowledge

The title is a little bit deceptive. It doesn’t mean that developers should walk around and tell everybody how many they know. Quite the opposite. Team leaders can organize meetings to let team member to tell other people what he do and how he do this. This is an excellent method to share the knowledge among all team members. It also motivates the source of information to better work.

Risks and problems

Despite these all tools mentioned above, there are also some problems that we can meet.

False help

One of the most dangerous risks in knowledge management is the following situation. Employee seems to be willing to spread his knowledge, but in fact, he teaches others only less important pieces of his expertise. It is quite hard to identify such kind of threat. Your only help can be other team members. They can tell you if they would need more knowledge to understand the topic thoroughly. If knowledge owner doesn’t pass all necessary knowledge for others, we should motivate/persuade him to do so.

Distributed knowledge

On the other hand, some teams knowledge can be distributed more equally and separably. This kind of specialization is also a problem because any part of your team can become a fragile element. Managers should show the value of sharing for each employee to encourage them to cooperate. One of the methods may be persuading them to introduce their knowledge in front of others (i.e. bragging mentioned earlier).

Single knowledge sources

Opposite situation also can be risky. If only a few team members store most of the project knowledge, it puts them in lot higher position than other developers. It also increases dependency on this people. In this case, we should take into consideration showing them how they can improve the quality of their work by sharing his duties with others.

Motivation to share

We can notice that most important part of this whole knowledge managing is employee motivation and their will to do this. Indeed, this is crucial to the success of this approach.

It is not all of the techniques for managing, but only chosen by me. What is your favorite method to introduce knowledge management into team?

Aktywne zabezpieczenie aplikacji webowej – AppSensor

Aktywne zabezpieczenie aplikacji webowej – AppSensor

owas-zabezpieczenie aplikacji

W poprzednim poście opisałem, czym jest mechanizm AppSensor. Chciałbym teraz przedstawić dokładniej jego sposób działania i w jaki sposób pozwala na zabezpieczenie aplikacji webowej.


Stosowanie tego mechanizmu umożliwia nam:

  • wykrywanie zagrożeń już w momencie próby ataku,
  • reagowanie na niebezpieczne zdarzenia w czasie rzeczywistym,
  • rozszerzenie spektrum wykrywania zagrożeń dzięki korzystaniu z kontekstu wykonywania akcji,
  • zabezpieczenie systemu przed nieznanymi jeszcze podatnościami programowymi.

Elementy składowe

Sama biblioteka składa się z następujących elementów:

  • punkty detekcji,
  • logowanie potencjalnych zagrożeń,
  • mechanizm analizy i rozpoznawania zagrożeń,
  • sposoby reakcji.

Elementy te, odpowiednio połączone, pozwalają na stworzenie spójnego mechanizmu przetwarzania wszelkich niestandardowych użyć systemu. Dzięki analityce jesteśmy w stanie zgrupować te anomalie i odpowiednio, proaktywnie na nie reagować.

Właśnie element analityczny jest jednym z najważniejszych mechanizmów w całej tej układance. To dzięki niemu możemy sprawić, że ataki będą blokowane, a błędy użytkownika nie spowodują blokowania jego pracy. Sposób wykrywania ataków zależy od tego, jak wygląda interfejs użytkownika systemu oraz jak dokładne walidacje są przeprowadzane w jego zakresie. Można to zaobserwować na poniższych rysunkach:


W przypadku, gdy nie wykorzystujemy walidacji po stronie klienta, otrzymanie numeru telefonu zawierającego myślnik nie jest niezykłe. Z kolei w przypadku, gdy odrzucamy tego typu znaki po stronie klienta, otrzymanie ich na wejściu metody API zdecydowanie świadczy o nieprawidłowym użyciu takiej metody.

Dodatkowo w niektórych elementach możemy zdecydować się na skorzystanie z usług zewnętrznego dostawcy rozwiązania. Tak jest w przypadku mechanizmu logowania potencjalnych zagrożeń. Przyjrzyjmy się bliżej wszystkim elementom biblioteki.

Rodzaje punktów detekcji

Zaczynamy od punktów detekcji. Są to reguły pozwalające na rozpoznanie specyficznych dla systemu sytuacji przekroczenia zasad przekazywania danych. Projekt AppSensor definiuje typowe punkty wykrywania. Dzielą się one na następujące grupy związane z:

  • zapytaniami do serwera,
  • autentykacją,
  • uprawnieniami,
  • walidacją danych,
  • zmianą trendów zachowania systemu.

Przykładami punktów detekcji mogą być:

  • próba ominięcia walidacji po stronie klienta,
  • próba operacji na zasobach, do których użytkownik nie ma uprawnień,
  • nadużycia przy próbach logowania,
  • próby przesłania niebezpiecznych znaków,
  • zbyt częste używanie funkcji niedostępnych z interfejsu użytkownika.


Ważnym elementem składowym biblioteki jest logowanie potencjalnych niebezpieczeństw. Można tu skorzystać z zewnętrznych usługodawców lub z własnego mechanizmu. W dużej mierze zależy to od tego, jakiego mechanizmu logowania używamy już w naszej aplikacji. Ze względu na potrzebę analizowania zagrożeń ważne jest umożliwienie odczytywania tych informacji z naszej aplikacji. Logowane informacje muszą posiadać kilka istotnych z punktu widzenia analizy właściwości:

  • datę i czas zdarzenia,
  • punkt styku, na którym wykryto naruszenie,
  • informację identyfikującą użytkownika,
  • wysłane informacje,
  • rodzaj wykrytego zagrożenia.

Rodzaje odpowiedzi

W odpowiedzi na rozpoznane zagrożenie możemy zastosować kilka rodzajów zachowań systemu, które mają na celu poinformowanie administratora i/lub utrudnienie dalszego ataku:

  • alerty bezpieczeństwa dla administratorów,
  • zwiększenie poziomu zabezpieczeń,
  • wylogowanie,
  • zablokowanie konta,
  • akcje w warstwie infrastruktury (np. blokowanie adresów IP),
  • dzielenie się danymi z innymi systemami.

Praca analityczna przy ustalaniu zagrożeń, reakcji i triggerów

Jak już wspomniałem, niezwykle istotne jest odpowiednie dopasowanie progów i zasad wykrywania, aby mechanizm ten nie był uciążliwy dla normalnych (popełniających błędy) użytkowników. Należy przeanalizować i dostosować ustawienia tak, aby pasowały do specyfiki aplikacji i firmy. Można przyjąć kilka różnych strategii działania:

  • nie zabraniaj niczego użytkownikom, lecz loguj ich działania i monituj administratorów,
  • informuj użytkowników o przekroczonych uprawnieniach i o monitorowaniu ich działań,
  • uzależniaj poziom zabezpieczeń od kraju pochodzenia użytkownika,
  • użytkownicy, którzy nie są zalogowani powinni mieć bardziej rygorystyczne ograniczenia,
  • wszelkie powtarzające się podejrzane zachowania o wysokim zagrożeniu powinny wylogowywać użytkownika i/lub blokować czasowo jego konto.

Integracje z innymi systemami

Implementacja może, a niekiedy nawet powinna obejmować integracje z innymi systemami. Powinna być ona rozpatrywana już podczas fazy analizy, ponieważ obejmuje zasady reakcji na zdarzenia. Przykładowo możemy rozpatrywać łączenie się z systemami:

  • w warstwie sieciowej infrastruktury (do blokowania adresów IP),
  • monitoringu,
  • wspomagającymi logowanie,
  • statystycznej analizy ruchu sieciowego.

Możliwości adaptacji

Do gotowego systemu zabezpieczeń możemy dodać różne modyfikacje, które usprawniają cały mechanizm, np.:

  • dynamiczne adaptacje progów wykrywania ataków (przy zwiększonej częstotliwości wykrywania niepoprawnych zachowań, możemy zaostrzyć kryteria akceptacji),
  • dynamiczne adaptacje zachowań w zależności od sposobów ataku.

W kolejnym poście opiszę architekturę rozwiązania, które chcę zbudować.

OWASP AppSensor – opis mechanizmu

OWASP AppSensor – opis mechanizmu



OWASP (Open Web Application Security Project) jest to organizacja non-profit mająca na celu analizę zagadnień związanych z bezpieczeństwem aplikacji i opracowywanie rozwiązań, które byłyby użyteczne zarówno dla organizacji jak i dla pojedynczych twórców oprogramowania. Organizacja ta działa otwarcie, a wszystkie materiały są darmowe i ogólnodostępne. Nie jest ona także związna z żadnym dostawcą oprogramowania i pozwala na niezależność w tym zakresie. Jej główną siłą napędową jest społeczność ludzi zainteresowanych tematem bezpieczeństwa. Tworzą oni narzędzia wspomagające zabezpieczanie i testowanie zabezpieczeń systemów komputerowych. Znane projekty to:

  • OWASP Zed Attack Proxy – narzędzie do automatycznego testowania bezpieczeństwa systemów
  • OWASP Top Ten – lista największych zagrożeń dla aplikacji webowych wraz z metodami zapobiegania im
  • OWASP OWTF – narzędzie do automatyzacji testów penetracyjnych

Wybór AppSensor

Od pewnego czasu interesuję się tematem bezpieczeństwa i dzięki temu trafiłem na ogranizację OWASP. Jest ona nastawiona w dość dużym stopniu na środowisko Java. Tak więc pisząc w .NET mogę korzystać z gotowych narzędzi OWASP, zaś korzystanie z bibliotek jest już dla mnie niemożliwe. Istnieją czasem porty bibliotek na platformę .NET, jednak nie są one dopasowane do tego środowiska. Projekt AppSensor zainteresował mnie swoją prostotą i możliwościami, które są z nim związane. Dlatego też postanowiłem zająć się jego implementacją dopasowaną dla webowych mechanizmów .NET w szczególności do WebAPI, ale z możliwością samodzielnego dostosowania do dowolnego frameworku np. Nancy czy ServiceStack.


Pomysł biblioteki AppSensor polega na tym, że w środowisku produkcyjnym aplikacja cały czas przetwarza różnego rodzaju informacje i akcje. Dzięki umieszczeniu wewnątrz kodu aplikacji odpowiednich punktów detekcji podejrzanych zachowań, jesteśmy w stanie na bieżąco, niemalże w czasie rzeczywistym, reagować na pojawiające się zagrożenia. W klasycznym podejściu ataki wykrywamy i blokujemy głównie na wejściu do aplikacji. Umożliwia nam to wykrycie podejrzanych zachowań takich jak wysłanie niepoprawnych ciągów znaków w requestach HTTP, co może sygnalizować próbę użycia np. SQL Injection. Nie biorą one jednak pod uwagę kontekstu w jakim wykonywane są te zapytania. System wykrywania, znając kontekst biznesowy konkretnego zapytania, jest w stanie wykryć więcej nadużyć, z większą trafnością. Jest na przykład w stanie wykryć zbyt częste próby logowania do aplikacji lub próby naruszenia uprawnień.

Podsumowując możemy powiedzieć, że AppSensor obejmuje wykrywanie nadużyć i reagowanie na zagrożenia:

  • zależne od kontekstu,
  • specyficzne dla danej aplikacji,
  • dynamicznie,
  • reagując w czasie rzeczywistym,
  • z możliwością adaptacji zasad reakcji.

Zasada działania

Cały mechanizm jest zasadniczo prosty w użyciu i składa się z trzech kroków:

  1. Detekcja – rozpoznanie nietypowego zachowania.
  2. Identyfikacja próby ataku – ocenienie czy wykryte zachowanie jest poza zakresem dopuszczalnych akcji użytkownika za pomocą interfejsu lub API.
  3. Reakcja – zastosowanie środka informującego lub zapobiegającego dalszym nadużyciom.

Identyfikacja ataku bazuje na prostym założeniu, że w większości aplikacji użytkowych, zbiór akcji dopuszczalnych jest rozłączny ze zbiorem akcji będących zagrożniem.


Kluczem jest więc odpowiednie odseparowanie tych 2 rodzajów zachowań. W podstawowej wersji tego mechanizmu można skorzystać z gotowego zbioru najpopularniejszych punktów detekcji zagrozeń

Bardzo dobrze przemówiło do mnie porównanie aplikacji z systemem wczesnego wykrywania zagrożeń i bez niego do banku zabezpieczonego i zarządzanego jak niektóre projekty informatyczne.