The document discusses the security challenges faced by Pervasive DataCloud2, an integration platform as a service (iPaaS) company. It outlines Pervasive's approach to protecting customers and infrastructure from external threats such as firewall rules, monitoring of OS events and API usage, and vulnerability scanning. It also details how Pervasive protects against internal threats through operational protocols, audits, access controls and segregation of duties. Additionally, the document addresses protecting customers from each other on shared elastic resources through availability monitoring, data encryption, and limits on cloud functionality.

1. Security Challenges in
Cloud Integration
Pervasive
DataCloud2
1

2. Pervasive Software
Global Software Company
• Tens of thousands of users across the globe
• Operations in Americas, EMEA, Asia
• ~250 employees
Strong Financials
• $49 million revenue (trailing 12-month)
• 43 consecutive quarters of profitability
• $40 million in the bank
• 22 consecutive quarters of active share buyback
• NASDAQ: PVSW since 1997
Leader in Data Innovation
• 24% of top-line revenue re-invested in R&D
• Software to manage, integrate and analyze data, in
the cloud or on-premises, throughout the entire data
lifecycle
2

3. Jason Wagner
Platform Manager
Pervasive DataCloud2
• Management of DataCloud2
architecture, engineering, and
operations teams
• 11 years experience in system
administration, web services and
integration architectures
• Previously:
– CRM and Business Intelligence Platforms
at Roche Tissue Diagnostics
– Integration Solutions Architecture at
Pervasive Software
3

4. Pervasive DataCloud2
• Integration Platform as a Service (iPaaS)
• Hosted Design Service to build and test
integration connectivity and workflows
• Management Console and API access to deploy,
schedule, and execute integration jobs
• Elastic job execution service to scale up and
down with customer needs and blackbox their
own SaaS and on-premise integration
applications
4

5. Pervasive DataCloud2
DataCloud2 provides a secure and intuitive way to Design,
Deploy and Manage both SaaS to SaaS or SaaS to On-
premise
SaaS ISV’s SI Enterprise IT
5

6. SaaS<->SaaS Integration
Cloud
Application
Legend
Administration &
Configuration Integration Developers
(No Customer Data) & End Users
Customer Data Flow
6

7. SaaS<->On-Premise Integration
Cloud
Application
Legend
Administration &
Configuration
(No Customer Data)
Customer Data Flow
Integration Developers
& End Users
7

8. Industry-Leading Connectivity
8

9. Our “Security” Mission
1. Protect Customers and Infrastructure from
External Threats
2. Protect Customers and Infrastructure from
Internal Threats
3. Protect Customers and Infrastructure from
Each Other
9

10. Protection from External Threats
• Strict Firewall Rules
• OS Event Monitoring
• API Usage Monitoring
• Vulnerability Scanning
• Breach Protocol
• Disaster Recovery Plan
10

11. Strict Firewall Rules
• Make sure firewall changes are not taken lightly –
challenging for us because our customers expect
to connect to MANY different endpoints
• Minimize the number of cloud boxes that are
exposed – continual audit of WHY? REALLY?
• Elastically allocated resources are the most
susceptible, so we are very cautious to lock down
inbound ports on these – even from our own
internal network access, e.g. Jump Servers
11

12. Strict Firewall Rules
(layered security groups)
Elastic Load Core Web and Job Scheduling and Elastic
Balancer Application Servers Queuing Service Worker Nodes
(Job Processors)
1 2 3
4
5 6
Job
Data Execution
Storage
12

13. Strict Firewall Rules
(protecting customer on-prem resources)
Deploy
Monitor
Customers with
Onramp on-premise apps
Framework
ERP/CRM
Load
Database
Analyze
Data prep Data collect
Aggregate Schedule
Join Partner mgmt Message Q
Transform Reformat
Match  Validate
Record linkage Profile Reports
Firewall
13

14. OS Event Monitoring
• Collect and monitor OS events for any changes to
permissions or alerts
• Some of the system events we are interested in:
– Failed login attempts
– Successful login attempts
– User access changes
– Group access changes
14

15. API Usage Monitoring
• Collect and monitor API usage for many kinds of
statistics
• Some of the statistics we are interested in:
– Failed login attempts
– Failed object access attempts
– Activity volume by operation
– Activity volume by user
15

16. Other Types of Monitoring
• Collect and monitor other types of statistics
• Some of the statistics we are interested in:
– Web page reads and write attempts
– Database activity, SQL injection
– URL modification, XSS
16

17. Vulnerability Scanning
• Regular intrusive and DoS attack simulations
during maintenance windows
• Include scans as part of SDLC and any significant
change to staging or production environments
• We use several popular services for external
scans, as well as our own “DoS/Brute Agent”
17

18. Breach Protocol
• Have breach protocol well-documented and easy
to find to prevent knee-jerk or panic reactions
• Suspected/confirmed breach (red flag)
– Quarantine/Triage/Investigation
– Notification/Transparency/Lessons Learned
• Limiting breach exposure
– Data Encryption
– Monitoring/Auditing
– Contractual Language
18

19. Disaster Recovery Plan
• It is important to be well-documented and spelled-
out contractually (whatever the plan is)
• Disaster recovery is more than just geographic
catastrophe and redundancy, but also:
– How do you recover from significant outage caused by
malicious activity?
– How do you recover from a vendor outage? Amazon?
Rackspace?
– How do you respond if critical/confidential data is lost
or compromised?
19

20. Protection from Internal Threats
• Sometimes Well-intentioned
• Operational Run Book
• Periodic and Spot Check Audits
• Access Activation/Deactivation Protocols
• Segregation of Duties/Change Control
• Shared Passwords
20

21. Operational Run Book
• Regular, weekly reports from all security related
tools:
– Cloud Firewall Configurations
– OS and API Monitoring Logs
– IDS/IPS Reports
– Availability and Performance Metrics
– Deployment/Patch/Source CM Reports
– Incident Reports
– Vulnerability Scan Report
• Good to have when you are auditor or auditee
21

22. Internal Audits
• Three types of audits to consider: Scheduled,
event-driven, and random spot check
• Some of the things we are interested in:
– Cloud Firewall changes reconcile with approved
change log
– User permissions reconcile with approved change log
– Approved change log is properly documented (WHY?
REALLY?)
– Customer usage rates fall within “expected” range
22

23. Access Activation/Deactivation
Protocol
• Work closely with Corporate IT and HR to
document roles, functions, and who has access to
what…
• Build matrices of access/permission changes
based on role and procedures that must take
place whenever someone leaves or joins the
team/company
• Don’t forget to account for contractors….
23

24. Segregation of Duties/CM
• Identify conflicts between engineering and
operations
– Formal escalation process
– Protocol for engineering access to production systems
• Enforce change control for security sensitive
changes
– Cloud Firewall modifications
– User or group access privileges
– Any kind of software or hardware patch in production
24

25. Shared Keys/Passwords
• AVOID, but make sure shared password reset
events are well-known/documented (Access
Activation/Deactivation Protocol)
• There are tools to assist – We have had success
with LastPass “secretly” sharing passwords, i.e.
the end user does not know the password and it
can be revoked from their LastPass account at
any time
25

26. Protecting Our Customers and
Infrastructure from Each Other
• Service and Data Availability
• Multi-Tenancy on Elastic Resources
• Handling Agents and Clients
• Alerts and Error Reporting
• Contract Language
26

27. Service and Data Availability
• Public Trust Site – We try to be as transparent as
possible with our external monitors, without
actually publishing the exact checks/procedures
• Internally make sure we have a pulse on real time
volumes – if in danger of NOT scaling, that could
be a security risk to us and our customers
• Data Integrity – this can get complex when you
start dealing with highly scalable data stores that
may not be inherently relational
27

28. Industry-Leading Connectivity
28

29. Multi-Tenancy on Elastic Resources
• This is a challenge for us due to the power and
flexibility of our product – we have to limit cloud
functionality vs. on-premise use
• We encrypt any kind of identifying information –
that we know about
• We spend a lot of resources “cleaning” up after
jobs are executed – we have to plan for some
loss of concurrency and efficiency because of the
continual need to prop up and tear down…
29

30. Agents and Clients
• We our own managed clients called agents for
on-premise connectivity, which typically are
connecting and communicating to the
“integrating” apps as well as DataCloud2
• Adds another dimension to what we have to track
in terms of not only users that are connecting, but
WHAT and WHERE are they connecting from?
• What about custom DataCloud2 clients built by
customers?
30

31. Alerts and Error Reporting
• Challenge for us is that our customers have all
kinds of different projects and metrics they are
interested in
• How are customers notified of different events
they may be interested in?
• It is possible that integration logs may have
confidential information – especially if they are
customized by the user/developer (see contract)
31

32. Contract Language
• How we behave is well-documented:
– Breach Notification Policy
– Backup Policy and Remedies
– Data Redundancy Policy
– Service Redundancy Policy
– History and Log Archival
• Customer data storage policy
– Types Allowed, HIPAA?
– How do you audit that your customers are compliant?
– Encrypt all? Or just what is necessary? (see contract)
32

33. Security Challenges in
Cloud Integration
The
End
Questions?
33