Tag Archives: security

Bringing an Efficient Home Care Solution to Life with WSO2 Technology

Senior citizens and disabled people—many in fragile health and requiring assistance—often have limited resources for managing their health and ensuring their security. Effective home care solutions allow such people to safely go about their day-to-day lives and enhances their quality of life. To aide home caregivers and patients, Raffaello Leschiera, a solution architect at Engineering Ingegneria Informatica, proposed a reference architecture for efficient home care using WSO2 technology at WSO2Con EU 2017.

Raffaello began by exploring the proposed reference architecture that connected and interfaced with all stakeholders, like the patient, his/her family and medical staff. Firstly, they need to collect data from medical devices in the patient’s home. Protocols like IEEE VU specifications are used and medical devices are mediated using Arduino and Raspberry Pi boards. Once collected, the data needs to be normalized and stored so it’s represented in the same way no matter which device it was collected from.

This data needs to run through analytics to monitor the patient’s health, process events and if needed, send notifications through various communication channels. Data integration channels using the HL7 standard protocol for health care is used to send this data to medical staff. The medical staff can then access it through web and mobile interfaces and an API gateway decouples all features from these user interfaces. And finally, the entire system needs to be synchronized and controlled by identity and access management to ensure security and privacy.

Reference architecture for a home care solution

Raffaello noted that WSO2’s comprehensive technology platform, particularly its integration and analytics capabilities, were the main reasons for picking WSO2 as their technology partner. The open source nature of the products was also a key deciding factor since Raffaello and his team work with many public administrators who prefer to adopt solutions that are completely open source. “WSO2 has a wide technology platform so you can find the right answer to every part of your problem,” said Rafaello. “And because all the products seamlessly integrate with each other it’s easy to focus on the domain problem rather than the technology problem,” he added.

To describe how WSO2 products were used for different tasks, Raffaello compared the home care solution to a football game:

  • Goalkeeper: WSO2 Microservices Framework for Java (WSO2 MSF4J) serves as the goalkeeper. This is the entire back-end of the system, which is based on lightweight microservices that are developed, deployed and monitored through MSF4J in a highly scalable and reliable manner with integrated security.
  • Defenders: WSO2 Data Analytics Server serves as one defender that receives data, analyzes it in real-time, and sends notifications. WSO2 Enterprise Integrator is the next defender who transforms disparate types of data into a normalized format and sends it to the hospital IT systems.
  • Forwards: WSO2 API Manager is one of the forwards, which faces the medical staff and is used to design, prototype and publish APIs and govern API usage. WSO2 IoT Server is another forward, which faces the medical devices for data collection, device management and protocol support.
  • Wings of the pitch: Here the WSO2 Identity Server takes care of all the strict security and privacy requirements.
  • Center of the pitch: Finally, WSO2 Governance Registry serves as the ‘Lionel Messi’ at the center of the pitch; in other words it governs the solution through surveillance just like how Messi would guide and lead his team to victory.
  • For this solution to work, Engineering Ingegneria Informatica needed a remote device that can track a patient’s movements within his/her home. Enter Joe Care (or the Joker pictured above). Joe Care is a remote presence device that is flexible and agile enough to move around the patient’s home. They used various technologies like Arduino boards, software that deals with movement and the sense of space as well handling (touch). It served as the medical eyes, ears, voice and fingers within the patient’s home.

    In the future Rafaello and his team aim to engage with users more, further analyze threat paths and include more technology like wearables that monitor movement and exercise. They would also like to create more intelligent early warning score models and move their entire solution to the cloud so more patients and operators can access it.

    Watch Rafaello’s presentation at WSO2Con EU 2017 below to learn more about their home care solution powered by WSO2.

How we handle security at WSO2

A Proactive Strategy for Security Management

Any decent software development organization generally has a well-defined set of policies and procedures for security management.

At WSO2, we – as in, the Platform Security Team – constantly collaborate with other product teams, customers and external security researchers to manage overall security of all WSO2 product. In this post, we’d like to talk about how we do this.


Part One: in the realm of code

code-944504_1280

I: Designing for security

The first stage of software design is the gathering of requirements. In open source software, we tend to use third-party code quite a bit – it’s how open source works: we stand on the shoulders of giants.
However, we can’t simply use what code we think is suitable.

The first check comes here. At WSO2, if we identify any kind of third-party code to be used, we need it to be first approved by the Engineering Management group, who are an internal group of seasoned architects who function at a directorial level. For us, security comes as a first priority, not as an afterthought.

The next set of checks come in the design phase. What are the communication protocols being used? How secure are they? Where is the data stored, and how? What endpoints are we exposing to the public? We go through a series of use cases to identify where this design can be broken, and work with the product design team to integrate our security concerns from the start.

II: Review, rinse, repeat

The next part is obvious: every developer is responsible for writing clean code [1, 2, 3].

Code written by each developer goes through a process of code quality reviewing overseen by members of the relevant product team and the Platform Security Team. When submitting the code for reviewing, the developer has to submit the static code analysis reports – generated using tools like FindSecBugs [4]. This is a mandatory security check in the reviewing process. Only upon fixing all issues spotted in the first pass is code is merged to the repository.

III: Testing with the automated grindhouse

At WSO2, we use Jenkins quite a lot for automating the build process. It builds individual components; it packages components together; it constantly builds and re-builds.

A large part of our security testing is integrated right into this process. Jenkins first performs the OWASP Dependency Check [5, 6], which analyzes the project dependencies and produces vulnerability reports. Even after the selection process in the first stage is complete, there can be some vulnerabilities that we haven’t spotted – especially if they’ve only been discovered extremely recently.

Next, Jenkins uses FindSecBugs as a plugin; during each automated build cycle, it checks individual components and generates vulnerability reports, which are in turn submitted to the security team for review.

Jenkins also uses the OWASP Zed Attack Proxy for dynamic code analysis [7, 8]. During the dynamic security analysis, the entire URL tree of the product is scanned and well-known attacks and exploits are automatically performed; the results are reported. These reports, too, are investigated by the respective product team as well as the Platform Security Team.

Once the testing is complete and a product is ready to be released, the respective product team has to receive security clearance from the Platform Security Team. If any known vulnerabilities are still listed in the reports, the product team has to justify to us the existence of the reported vulnerability – a pretty hard job.

We find that developers may write code following all the best security practices, but when the code is merged together, it might still open up a vulnerability because of how everything integrates together.


 Part Two: when humans happen

astronaut-and-robonaut-shake-hands

I: Preparing for the real world

There’s a saying: no battle plan survives contact with the customer. Although security standards and processes are followed to the letter, our products have to run in the real world.

One of the most important things is building awareness. We put together a set of deployment patterns, security recommendations, and best practices to be followed when deploying our products; we also conduct public webinars for making awareness in security related topics for WSO2 users, which are available at wso2.com/library/webinars.

II: Building internal Champions

Sometimes there is a gap between the product team and the security team, since the members of the security team might not be specialists of the product.

In order to bridge this gap, we’ve have someone we call the ‘Security Champion’ in each product team. The Security Champion of the product team is responsible for maintaining the safety of the product and conducting vulnerability assessments.

All Security Champions (from different product teams) directly work with the Platform Security Team and share knowledge and experiences with each other. They also share the knowledge of the Platform Security Team back with the members of the product teams.

III: Patching up 

When a vulnerability is detected in a product, patches are created for all the versions that the issue exists in. If the severity of the vulnerability is catastrophic, these patches will be released to all customers immediately. If the severity is not catastrophic, we aggregate all patches developed during the month and release the lot at the end of the month as a security bulletin.

When a patch is ready, it’s sent out through WSO2 Update Manager (WUM), added to wso2.com/security-patch-releases and publicly announced. Every version of any given product supported by WUM will receive the patches automatically. Note that unless the product is supported by WUM, security patches are publicly released only for the very latest version of the products.

Moving forward, we’ve started recording this in Documentation at docs.wso2.com/display/Security/Security+Advisories for the sake of preserving more patch information. This effort is still recent but will add up over time.

IV: Responding to Vulnerability Reports

Technology gets updated every day and there are always new vulnerabilities and exploits discovered. We welcome contributions from our user community, developers, and security researchers to reinforce our product security. Over the years, a great many people – both customers and from the community -have helped us make our products the best they can be.

When someone reports a vulnerability, we try to verify the issue and respond to the reporter. If the vulnerability is a true positive, the patching process begins.

Generally, we do ask that the reporter refrains from publicly disclosing the vulnerability until we’ve patched it – this is to prevent anyone who might be vulnerable from being targeted.

We’re always looking for ways to make this easier. For example, we’ve set up wso2.com/security to serve as an easy, central point for our community to report issues. As time goes on,


 

References

[1] OWASP Secure Coding Practices https://www.owasp.org/index.php/OWASP_Secure_Coding_Practices_-_Quick_Reference_Guide

[2] Oracle Secure Coding Guidelines for Java http://www.oracle.com/technetwork/java/seccodeguide-139067.html

[3] SANS Secure Coding Guidelines https://www.sans.org/course/secure-coding-java-jee-developing-defensible-applications

[4] Static Code Analysis for Java using FindBugs Plugin and Identifying Security Bugs with FindSecurityBugs Plugin
http://tharindue.blogspot.com/2016/06/static-code-analysis-for-java-using.html

[5] OWASP Dependency Check CLI – Analyzing Vulnerabilities in 3rd Party Libraries http://tharindue.blogspot.com/2016/10/owasp-dependency-check-cli-analyzing.html

[6] Checking vulnerabilities in 3rd party dependencies using OWASP Dependency-Check Plugin in Jenkins https://medium.com/@PrakhashS/checking-vulnerabilities-in-3rd-party-dependencies-using-owasp-dependency-check-plugin-in-jenkins-bedfe8de6ba8#.ipu0b8u4o

[7] Dynamic Scanning with OWASP ZAP for Identifying Security Threats https://medium.com/@PrakhashS/dynamic-scanning-with-owasp-zap-for-identifying-security-threats-complete-guide-52b3643eee04#.nyy1fwiok

[8] Automating the boring stuff in development using ZAP and Jenkins : Continuous Integration
https://medium.com/@PrakhashS/automating-the-boring-stuffs-using-zap-and-jenkins-continues-integration-d4461a6ace1a#.jtknrzajt