Cyber Security at Pugpig
We take security seriously at Pugpig. We host content for some of the world's highest profile media brands, and we treat it accordingly.
Some of the measures we have in place are:
We run Amazon GuardDuty across all of our systems
We run many AWS Web Application Firewall Rules
Rackspace monitor our servers for unusual activity
We do not have a local network, or own any servers. Everything is on AWS which reduces the number of attack vectors
We automatically patch our servers and Wordpress installations with any security patches. We would rather risk downtime than have vulnerable systems
We advise all of our clients that have a dedicated Pro/Site server to provide us with the IP ranges which we use to can lock down CMS access
Our CMS servers do not take consumer traffic. Everything is served by our Fastly CDN
All our systems will only use HTTPS (with A+ certificate ratings from SSL Labs)
We limit access to our production systems to only the staff that need it
We store all passwords securely in 1Password, and any sensitive information given to us by clients should be done in an encrypted way using www.keybase.io
We encourage our clients to run penetration tests against our systems - it helps us harden our systems. We normally have this happen between 2 and 4 times a year. If you wish to run one, please do let us know as we need to inform Amazon
For clients that do NOT provide a PKCE flow for login, we do proxy the username and password through our servers. We only allow HTTPS POSTS for this, and do not store or log any of these details.
Native App Security
Here is an FAQ about approaches in the native applications.
What technology do you use for the Bolt native apps?
The apps are written natively using Swift (iOS) and Java (Android). We do not use cross-compiling frameworks. We do use embedded native webviews to render timelines and content as we believe HTML and CSS give publishers more flexibility in the content of their presentation and embeds in this way. We use the recommended secure web views for any sensitive user login/registration screens using the PKCE flow.
Do you do an Application Integrity Check?
We do not. Our apps only run on mobile platforms which require code signing, we get both of these for free, as we sign our code and the platforms will not run code if the signature fails, which would happen if the binary was changed in anyway.
Do you use Code Obfuscation?
We do not. Our approach to security treats end-user devices as completely untrusted. We perform all authorisation/entitlement checks server-side only, on trusted hardware within our control. We also abide by NIST’s recommendation that “System security should not depend on the secrecy of the implementation or its components.” See TETRA:BURST for a recent high-profile example of failure of security through obscurity.
Do you use Certificate or Public key pinning?
We do not use certificate pinning.
Do you provide an In-App Keypad?
No. We use only the Operating System's user input.
Do use use Device binding, linking mobile device information to mobile application?
We do not attempt to read unique device information, as this is not allowed by the platforms. Our advertising integrations, if used, may use unique ad tracking information, but only with end-user consent. Entitlement concurrency can be managed server-side by limiting the number of concurrent refresh token streams.
Do you do Detection and block of rooted or jailbroken mobile devices?
We do not do such detection. We treat all end-user devices as untrusted. (See also above.)
User Data Policy
Note that we never store any end user data on any of our systems, so there is no risk of a user data breach. The only content we store is the ready to publish editorial content. Our biggest risk is the defacement of a publication or website. This has never happened in our 10 years of operation, but we remain vigilant.
Notification of Breaches
If any breach or failure should occur, clients are notified via our Status Page (to which you can subscribe) at https://status.pugpig.com/